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 | 8086 is COOOOL (Announce)

posted by Rugxulo Homepage, Usono, 07.09.2010, 16:59

> > What about the RxDOS (GPL) hack using A86 (shareware) instead of MASM?
>
> RxDOS 7.1.5 is trash.

I don't know. It seems somewhat incomplete. Also seemed floppies I used for it got corrupted and had to be rewritten over and over. Maybe that was my fault, dunno. (Also never could figure out which version was the last / most recent.) But at least it tries to support FAT32 and LFN ("modern" technology). Still, it's GPL, so we can't complain! :-)

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.

> So is A86;

Whoa! Kinda strong statement. I don't think anybody reasonably thinks A86 is crap. It's not. But yeah, it hasn't been developed since 2000, so it only supports SSE1 *sniff* j/k. :lol2: I'll admit that it has some quirks that I don't like, and it's fairly limited in OS support (obviously), but it works fairly well for what it does. There are some assemblers that mimic A86 in minor ways (due to being written in it?), but they are incomplete in their compatibility too. Face it, x86 asm has no standard, so everyone varies the syntax a fair bit.

> and it kinda defeats the purpose of using
> a self-recompiling assembler if you can't compile it because you lack the
> source code.

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!

> (Actually, we don't even know whether A86 really is self-compiling.)
A86 is (allegedly) self-compiling, if you believe the author.

> > Even Japheth compiled one tiny piece of it with JWasm.
>
> 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.

> > 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.

> > Then again, no expectations, I think he's just doing it
> > for fun, no timetable.
>
> True. Expect releases in early 2038. (In the year 2038, that is.)
The next Y2K problem. ;-)

> > (And Debian hates OSI's approval of the Sybase license.)
>
> It's still the best 16-bit DOS compiler though, isn't it? If I had the
> choice maybe I would use a 2-clause BSD compiler with OpenWatcom's
> capabilities instead.
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.

* 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. What does the compiler have to do with the license of the compiled output? In this case, nothing, but they are being more than a little silly. (Or maybe they're worried about patents, but I'd be VERY surprised if anybody tried anything. And no, VFAT isn't in FreeDOS proper, so that can't be a good reason against it.)

* 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.

> > Any of those can compile FreeDOS's KERNEL.SYS.
>
> Now you could back up TC's alleged ability to produce small code. Do you
> have the necessary setup to compare a TC compile of TFK with an OpenWatcom
> compile?
What is TFK?

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??).

> > > For 8086 development just binary and OMF are sufficient.
> >
> > ELKS probably uses what BCC/Dev86 uses, AS86 (a.out?) I guess.
>
> That's a somewhat exotic environment. Besides, they probably don't have
> NASM syntax source code anyway, do they?
No, but if someone wanted to write for ELKS with NASM .... I'm only mentioning this to be complete. ELKS has even less users than FreeDOS (not many)!

> > Of course, FreeCOM 0.84-pre2 needs 186+ for having all features.
>
> Ahahahahah. Are you kidding us, or are they? True, the new 186 instructions
> are useful, but they can all easily be replaced by equivalent 8086 code.
> With a few macros, you probably wouldn't even have to touch the code.
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.

> * POPA/PUSHA
> * SHL/SHR/SAR/ROL/ROR/RCL/RCR with immediate
*ding ding* These are probably the only affected instructions. 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. I haven't rebuild FreeCOM lately.

> > and nobody complained.
>
> How about somebody complain about it now?
About HimemX? The patch is on this forum somewhere. Somebody (RayeR?) did test it, and it didn't work until patched. Eric Auer even showed some interest, but he seemed to (apparently) want me to patch / upload it. Well, it's not like I really expected him to either. I dunno, everything's just so disorganized, too much to do, not enough volunteers, etc.

---
Know your limits.h

Post reply
 

Complete thread:

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