Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

NASM version 2.09 available | A86 and kernels (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 07.09.2010, 18:42

> (Also never could figure out which version was the last / most recent.)
Still 7.1.5, from the FreeDOS mirrors. It's also the only one clearly licensed under the GPL. "a7.1.5" is the A86 port of that version. There's numerous other releases but all either without or with non-free source, and mostly older.

> Still, it's GPL, so we can't complain! :-)
I complain as a user, not as a developer. No, wait, I do complain as a developer too. There's nothing in the GPL to prevent me from that :-)

> > So is A86;
>
> Whoa! Kinda strong statement. I don't think anybody reasonably thinks A86
> is crap. It's not.
Yeah.. maybe it's a little too strong, but A86 isn't sophisticated at all. Even include files weren't supported for several years! The local label mechanism is crap and doesn't work together with D86 either. Given that the assembler and debugger are highly integrated, I would assume that to work. D86 also isn't very sophisticated, technically. For example, it catches Int21.4C of the debugged code, presumably with an Int21 hook - a nice feature? Not only that, it's also necessary for no-program operation because D86 doesn't set up a child process that way (and would then terminate itself by 21.4C, incompletely, because it doesn't catch its own termination). Besides, the whole symbolic debugging and most of D86's interface is designed for programs running in exactly one segment. The former is virtually unusable for large, or multiple, programs (f.e. kernels) in multiple segments.

What I have to give D86 is its good implementation of "memory windows" (automatically updated data dumps) and the extensive online help. Surely just writing all the text took some effort, let alone programming the automatic context-sensitive displaying of the correct help pages.

> But yeah, it hasn't been developed since 2000, so it only supports SSE1
That really doesn't bother me.

> Well, the point was that A86 can run on 8086 and compile that fork of
> RxDOS, which is what DOS386 wanted (in theory). I didn't say it was ideal,
> just saying it exists, so it's better than nothing!
It has been acknowledged. I just wouldn't develop anything on A86 no matter how much I care for 8086 compatibility.

> > (Actually, we don't even know whether A86 really is self-compiling.)
>
> A86 is (allegedly) self-compiling, if you believe the author.
That's what I said. Although I don't really doubt that it is self-compiling: unless we have the source, we can't know for sure.

> > RxDOS 7.1.5 is trash.
>
> [...]
 >
> But at least it tries to support FAT32 and LFN ("modern" technology).
 >
> [...]
 >
> Probably broadly similar to DOS-C, which was originally just an int 21h
> API, not all the extra bells and whistles. It didn't run everything under
> the sun either originally.
 >
> [...]
 >
> > Yeah. You could arguably make (a)7.1.5 work with JWasm with little
> effort,
> > but it's still trash.
>
> I assume you mean due to bugs. That, to me, is more of a deal-breaker than
> incompleteness.
I stopped recording specific bugs about 4 months into the hacking. There's no bugs any more; instead, everything just works hardly at all. I don't think DOS-C ever was that bad, but I didn't read Pat's book "FreeDOS Kernel" looking for problems specifically, and never looked at other early DOS-C source code.

> > > But cm's NASM fork is probably better.
> >
> > It's neither a fork nor a port any more. I've probably rewritten at
> least
> > 50% of the code by now.
>
> Well, it's still a derivative.
The kernel still is. But what if I get to a point where I've rewritten everything? Could I release it as my work? Would anyone even care to check the code? Probably not. (Don't misconstrue this. I don't want to steal any of Mike's code. Rewriting everything just really is a possibility.)

> The next Y2K problem.
Oh you. I wasn't aiming for that, 38 just is a nice number.

> Here's what bugs me about that:
>
> * Nobody at Sybase probably cares anymore. Nobody seems interested. They
> don't seem to actively maintain or even ever plan to change the license. So
> it's pretty much "dead" legally, IMHO.
Like about 95% of DOS software, only for that we don't get the source at all. So it was pretty nice of them to give us even "semi-free" source code, don't you think?

> * OSI approves the license, tons of it has been reworked, tweaked, improved
> since then, but it's still not good enough for Debian. And they somehow
> take that to mean that FreeDOS proper should stay in "multiverse", which
> seems odd to me.
Ah, that's where you're coming from.

> What does the compiler have to do with the license of the compiled output?
They're Linux zealots. They can't accept that there might be cases were accepting binaries instead of recompiling everything might be better, even if these binaries are just for a deprecated, foreign architecture no one supports.

Solution: Change people. Or use a workaround, for example, provide a free-free-free compiler for them. (Extend gcc? Use some existing DOS compiler with GPL or a really free license?)

Oh! Try embedding the KERNEL.SYS file in a C source file then compiling that with gcc :-D

> (Or maybe they're worried about patents, but I'd be VERY
> surprised if anybody tried anything.
What with the kernel developers declining to debug or even thoroughly test MS-DOS, all patents applicable to TFK would be equally applicable to Linux (the kernel).

> And no, VFAT isn't in FreeDOS proper,
> so that can't be a good reason against it.)
VFAT is in Linux, so what?

> * There is no real effort to port FreeDOS to any other compiler. Of course,
> what else is there? There are other C compilers, but almost all of them
> only support 32-bit. So what, we should only use a 32-bit DOS now? Maybe.
And write proper boot loading and PM start-up code. That means in assembler, you hacks! :-P

> What is TFK?
The FreeDOS Kernel. Because someone worked on some private (fork?) project they called DOS-C, they objected to me calling the recent FreeDOS kernel DOS-C on the mailing list, so I just call it The FreeDOS Kernel all the time. Calling it KERNEL.SYS isn't quite right in some situations.

> My P166 has OW 1.8 and TC++ 1.01. Both are freely available (loosely
> speaking, you pedants). For instance, BEF.C from bef-2.21.zip (Chris
> Pressey) compiles and UPXes to approx. 17k in OW but 10k in TC++. So it is
> smaller, but only because (says Tom Ehlert) that it's a "dumber" compiler
> (one-pass??).
Seems somewhat extreme. As pedant, I believe a one-pass compiler wouldn't be better than a multi-pass one. Maybe bad OW configuration (use "-os" or so to optimize for size)? There might also be more/better run-time checks in OW.

> ELKS has even less users than FreeDOS (not many)!
How would that be possible now. ;-)

> It has something to do with size, I never looked to closely. Yes, I know,
> it shouldn't be an issue, but it is. Blame the lame-o C compilers.
There's at least one PUSH imm opcode in one of the (NASM) source files. And FreeDOS is just silly enough I would expect something like that of them. Even if there are issues with segment size, no problem, split the offending code segment and do calls between these segments through pointers fixed up (preferably by the assembler swopping code).

> Actually, I
> can't remember, it may just be something like LOADFIX and/or something else
> trivial that isn't in the pure 8086 build.
Given that LOADFIX is absolutely useless on true 8086 and 80186 processors (they only address 1024 KiB of memory, there's no HMA or A20) you selected a bad example ;-)

As I said, the FreeCOM version I examined (0.84-pre XMS_Swap, 2005-07-20) really does have 8086-incompatible code. (Only seen it in an XMS call function though, and XMS doesn't exist on true 8086 machines, does it? Still bad enough.)

> I haven't rebuild FreeCOM lately.
Either way, fixing the broken 8086 compatibility should be a very easy task.

> I dunno, everything's just
> so disorganized, too much to do, not enough volunteers, etc.
I fondly regard Robert's mail asking about how FreeDOS 1.1 tasks are organized. And Pat's very inexplicit answer... "assessing what needs to be done in order to scope out the effort". Heheheheheh.

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22649 Postings in 2111 Threads, 402 registered users, 844 users online (1 registered, 843 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum