DOS ain't dead

The NASM developers have released NASM version 2.09 on 24 August 2010.

Home page: http://www.nasm.us/
Download: http://www.nasm.us/pub/nasm/releasebuilds/2.09/

Changes:
? Fixed assignment the magnitude of %rep counter. It is limited to 62 bits now.
? Fixed NULL dereference if argument of %strlen resolves to whitespace. For example if nonexistent macro parameter is used.
? %ifenv, %elifenv, %ifnenv, and %elifnenv directives introduced. See section 4.4.9.
? Fixed NULL dereference if environment variable is missed.
? Updates of new AVX v7 Intel instructions.
? PUSH imm32 is now officially documented.
? Fix for encoding the LFS, LGS and LSS in 64-bit mode.
? Fixes for compatibility with OpenWatcom compiler and DOS 8.3 file format limitation.
? Macros parameters range expansion introduced. See section 4.3.4.
? Backward compatibility on expanging of local sigle macros restored.
? 8 bit relocations for elf andbin output formats are introduced.
? Short intersegment jumps are permitted now.
? An alignment more than 64 bytes are allowed for win32, win64 output formats.
? SECTALIGN directive introduced. See section 4.11.13.
? nojmp option introduced in smartalign package. See section 5.2.
? Short aliases win, elf and macho for output formats are introduced. Each stands for win32, elf32 and macho32 accordingly.
? Faster handling of missing directives implemented.
? Various small improvements in documentation.
? No hang anymore if unable to open malloc.log file.
? The environments without vsnprintf function are able to build nasm again.
? AMD LWP instructions updated.
? Tighten EA checks. We warn a user if there overflow in EA addressing.
? Make -Ox the default optimization level. For the legacy behavior, specify -O0 explicitly. See section 2.1.22.
? Environment variables read with %! or tested with %ifenv can now contain non-identifier characters if surrounded by quotes. See section 4.10.2.
? Add a new standard macro package %use fp for floating-point convenience macros. See section 5.3.

---
Forum admin

> The NASM developers have released NASM version 2.09 on 24 August 2010
> Fixes for compatibility with OpenWatcom compiler and DOS 8.3 file format

So it compiles in DOS with Open WATCOM ? This looks like good news, although I personally don't have that big need to compile my NASM from source

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> So it compiles in DOS with Open WATCOM ? This looks like good news,
> although I personally don't have that big need to compile my NASM from
> source

Don't know, but that's probably what they addressed there (they stripped down most source code file names to SFNs).

I today got it to compile for an 8086 DOS target after stripping the supported instruction set down to 686 - both executables (NASM and NDISASM) appear to work, but NASM.EXE is a 460 KiB file which means that it barely runs at all and usually crashes if I try to assemble anything at all (at least I hope the crash is only due to running out of memory). NDISASM.EXE works fine though, and is just about 110 KiB.

So NASM still can be compiled for 8086 systems. If I have time for that, I might look into stripping it down better to get the executable's size down. Maybe write some code to let it use disk or XMS swapping? Hmm.

---
l

> that's probably what they addressed there (they stripped
> down most source code file names to SFNs)



> appear to work, but NASM.EXE is a 460 KiB file which means that it barely
> runs at all and usually crashes if I try to assemble anything at all

useless ...

> NDISASM.EXE works fine though, and is just about 110 KiB.



> So NASM still can be compiled for 8086 systems. If I have time for that, I
> might look into stripping it down better to get the executable's size down.

If you get something useful please announce and release it

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> NASM.EXE is a 460 KiB file which means that it barely
> runs at all and usually crashes if I try to assemble anything at all (at
> least I hope the crash is only due to running out of memory). NDISASM.EXE
> works fine though, and is just about 110 KiB.
>
> So NASM still can be compiled for 8086 systems. If I have time for that, I
> might look into stripping it down better to get the executable's size down.
> Maybe write some code to let it use disk or XMS swapping? Hmm.

Maybe time to throw out those 8086's and 80186, and raise the limit to a more modern machine, like a 286 ?

> > NASM.EXE is a 460 KiB file which means that it barely
> > runs at all and usually crashes if I try to assemble anything at all (at
> > least I hope the crash is only due to running out of memory).
> NDISASM.EXE
> > works fine though, and is just about 110 KiB.

This is probably because of all output formats enabled by default. You'll have to manually disable non-DOS targets (win32, macho) in NASM.H or OUTPUT.H or whatever (I forget), which is what was typically done in old 0.97/0.98 days. Then it should run a little better (but not much). Last 16-bit build is for 0.98.39, found on SourceForge, which lacks x86-64 support which isn't needed here anyways. (Turbo C will produce smaller code, I think, but I may be thinking of after UPX, which wouldn't help shrink RAM use. Make sure to use -os or -oxs or whatever for OpenWatcom. EDIT: Oops, TC doesn't support C99, doh.)

> > So NASM still can be compiled for 8086 systems. If I have time for that,
> I
> > might look into stripping it down better to get the executable's size
> down.
> > Maybe write some code to let it use disk or XMS swapping? Hmm.
>
> Maybe time to throw out those 8086's and 80186, and raise the limit to a
> more modern machine, like a 286 ?

Yes, if he's using XMS at all in the future, it will be 286+ only. I believe cm is using NASM 2.04+ features in his port of RxDOS. While I don't personally see a huge need to have a 16-bit NASM just to assemble that, it would still be cool to have. I guess he likes the new macro features or whatever.

---
Know your limits.h

> This is probably because of all output formats enabled by default. You'll
> have to manually disable non-DOS targets (win32, macho) in NASM.H or
> OUTPUT.H or whatever (I forget), which is what was typically done in old
> 0.97/0.98 days. Then it should run a little better (but not much).

Already thought about that. I'll probably disable macho and elf (maybe rdf too), but win32 and coff might be useful for HX and DJGPP development. I'll also have to look into making these things optional via C preprocessor variables so that we might get these patches into the official NASM builds. That could be accomplished with an additional makefile for Open Watcom that only has 16-bit DOS as target. (The label dos is currently used for the DPMI output format in the Open Watcom makefile.)

> which lacks x86-64 support which isn't needed here anyways.

As I wrote, I already disabled post-686 instructions, including all IA64-emulation and AMD64 stuff. I'll look into disabling support for these architectures in other places except the expression evaluator (that would be too much work).

I thought about disabling post-386 instructions too. This way, one would be able to create basic 32-bit programs with the 16-bit build, but anything else would require the DJGPP build.

> Make sure to use -os or -oxs or whatever for OpenWatcom.

Yep, already done. I also tested other different options. I have to manually enter different data segment names to avoid overflowing the default segment. All the data needs to be handled as far too. (Large or Huge memory model.) Maybe Open Watcom can be talked into moving data to overlays, which may or may not enable segments or even single items larger than 64 KiB.

> EDIT: Oops, TC doesn't support C99, doh.

I really wasn't looking forward to extend my toolchain to the semi-free TC either. (You only get the binaries, and only from that one hidden museum site.)

> > Maybe time to throw out those 8086's and 80186, and raise the limit to a
> > more modern machine, like a 286 ?

Actually, the oldest real machine I'm running has a 586-class CPU. Porting it to a 16-bit platform is just for fun.

> Yes, if he's using XMS at all in the future, it will be 286+ only.

It could be optional, with disk swapping if no XMM is installed. Because, you see, I did mention disk swapping and XMS.

> I guess he likes the new macro features or whatever.

Right. Besides, I'm usually with the latest daily build of NASM. Some of my code right now probably won't even assemble with 2.07, and I'm already planning to use the better preprocessor of the upcoming 2.10 release. 0.98.xx was a joke compared to what we get now. (Also, I don't know whether you are allowed to use 2.06 or older releases under the 2-clause BSD license. That's important to me for ideological reasons.)

---
l

> Already thought about that. I'll probably disable macho and elf (maybe rdf
> too), but win32 and coff might be useful for HX and DJGPP development.

Well, it's a slippery slope. The only format that definitely can't be used in DOS (that I know of) is Mach-O. Everything else has weird hacks or libraries that can work (EMX or DJELF or BCC/Dev86).

I checked yesterday, the old 0.98.39 16-bit .EXE (I think) supported bin, obj, as86, and win32.

> That could be accomplished with an additional makefile for Open Watcom that
> only has 16-bit DOS as target. (The label dos is currently
> used for the DPMI output format in the Open Watcom makefile.)

2.09's "wmake -f mkfiles\openwcom.mak dos" doesn't work as-is in pure DOS with DOS-hosted compiler due to cmdline limits (128 bytes? 126?).

> I thought about disabling post-386 instructions too. This way, one would be
> able to create basic 32-bit programs with the 16-bit build, but anything
> else would require the DJGPP build.

486 and 586 are pretty minor, so they should also be included, IMHO, but everything beyond that is overkill.

> Yep, already done. I also tested other different options. I have to
> manually enter different data segment names to avoid overflowing the
> default segment. All the data needs to be handled as far too. (Large
> or Huge memory model.) Maybe Open Watcom can be talked into moving
> data to overlays, which may or may not enable segments or even single items
> larger than 64 KiB.

Unpacked, the old 16-bit 0.98.39 .EXE is less than 250 kb, which should leave ample memory (famous last words) for reasonable projects. (You could argue that they should be split into separate .OBJs anyways if bigger.)

> > EDIT: Oops, TC doesn't support C99, doh.
>
> I really wasn't looking forward to extend my toolchain to the semi-free TC
> either. (You only get the binaries, and only from that one hidden museum
> site.)

I know, I just meant it generates smaller code (I think).

> Actually, the oldest real machine I'm running has a 586-class CPU. Porting
> it to a 16-bit platform is just for fun.

Jim Leonard hasn't been as active as before, he hasn't responded to some basic e-mails, so maybe he's losing interest, else I'd suggest you e-mail him (so he could test on his 8088). Perhaps Mike Chambers would be interested??

> It could be optional, with disk swapping if no XMM is installed. Because,
> you see, I did mention disk swapping and XMS.

Ralf Brown's SPAWNO?? (Don't forget EMS! Trixter's 8088 has 2 MB of real EMS!)

> > I guess he likes the new macro features or whatever.
>
> 0.98.xx was a joke compared to what we get now.

I personally never fell in love with all the HLL stuff that MASM, etc. added, but feel free to use whatever floats your boat!

> (Also, I don't know whether
> you are allowed to use 2.06 or older releases under the 2-clause BSD
> license. That's important to me for ideological reasons.)

Dunno, doubt it, but LGPL ain't so horrible either. I just think "an assembler is an assembler", and "it's good enough" or whatever. All the string and preprocessing stuff isn't as useful (to me personally).

> The only format that definitely can't be used
> in DOS (that I know of) is Mach-O.
I spotted that a C++ (OSX) based Mach-O file viewer now exists on SourceForge
http://sourceforge.net/projects/machoview/ the project was registered on 15-July-2010.

> Jim Leonard hasn't been as active as before,
From following his blog ( http://trixter.wordpress.com/ ) I noted a few months back that he started a busy new job. He has also been busy with Mind Candy 3.

> so maybe he's losing interest,
Lol, somehow I think that will only happen when hell freezes over ;)

> him (so he could test on his 8088).
FYI, presently I still own several 8086's, 80186's, 286 etc. Long term I'm considering my options with regards to donating to a museum or similar. You can't beat real hardware. Unfortunately at this present time I'm not setup to test stuff easily or to put it another way most of my kit is in storage and I simply I haven't had a chance to set myself up again with my multiple switch box etc. But I plan to have a test rack of some sorts again where I can literally quickly test stuff with a 8086, 80186, 286, 386 etc.

> Well, it's a slippery slope. The only format that definitely can't be used
> in DOS (that I know of) is Mach-O. Everything else has weird hacks or
> libraries that can work (EMX or DJELF or BCC/Dev86).

Then users of the port would have to compile that on their own, excluding other output formats if necessary.

> I checked yesterday, the old 0.98.39 16-bit .EXE (I think) supported bin,
> obj, as86, and win32.

Thanks. AS86, AOUT, AOUTB and the Intel/Motorola hex formats would be definitively excluded too.

> 2.09's "wmake -f mkfiles\openwcom.mak dos" doesn't work as-is in pure DOS
> with DOS-hosted compiler due to cmdline limits (128 bytes? 126?).

Doesn't OpenWatcom know of CMDLINE= maybe?

> 486 and 586 are pretty minor, so they should also be included, IMHO, but
> everything beyond that is overkill.

Yeah.. maybe basic 686, but MMX contains lots of instructions. It could also save space to leave out the MMX register handling if I would find a way for that.

> Unpacked, the old 16-bit 0.98.39 .EXE is less than 250 kb, which should
> leave ample memory (famous last words) for reasonable projects.

That's what I'm concerned about. I don't think it's enough. My sources are up to 600 KiB per project, and I think NASM needs to store the complete tokenized source in memory. Even if it strips all the comments, that's still at least 200 KiB.

> (You could
> argue that they should be split into separate .OBJs anyways if bigger.)

No. Complicated section arrangement isn't possible with OMF .OBJ output format as easily as with NASM's bin output format. (Writing a kind of post-processor or specialized linker would make it easier, but I don't consider this an option since it's more work and complicates the build process.)

> I know, I just meant it generates smaller code (I think).

I don't think code size is much of an issue, most code appears to fit in one segment. Besides, wasn't Watcom one of the better compilers too?

> (so he could test on his 8088).

I have at least one 16-bit x86 emulators (i.e. it emulates only the 186 instruction set) so debugging would probably be done within that.

> > It could be optional, with disk swapping if no XMM is installed.
> Because,
> > you see, I did mention disk swapping and XMS.
>
> Ralf Brown's SPAWNO??

What? No. I consider myself able to write code which swaps data in and out of memory to XMS or a file as necessary. The hardest part would of course be to detect when to do that on what of NASM's data, but that's exactly the code I would have to write anyway if using someone else's XMS/file access code for NASM.

> (Don't forget EMS! Trixter's 8088 has 2 MB of real EMS!)

Good call.

> I personally never fell in love with all the HLL stuff that MASM, etc.
> added, but feel free to use whatever floats your boat!

Or bloats my foat? Hmmmm. No, really, most of the macros I use are for stuff like writing data (tables..), messages and exceptional code that can't be achieved unless using db (like for patching). Then there's some macros that deal with NASM command line parameters so I could define an option "TEST" and then either say nasm -D_TEST or (equivalent) nasm -D_TEST=1 or nasm -D_TEST=0. The macros automatically assign a default value to the single-line macro _TEST so that I can use it like %if _TEST && other_condition or as db '0'+ !!_TEST everywhere in the source, even if it wasn't defined on the command line. %ifdef is overrated.

My code, on the other hand, contains only few or no HLL-like macros known from other source code (IF, WHILE, etc) with the exception of debugging stuff; like d4bp which writes an int3 opcode only if the option DEBUG4 is enabled, and d4message "Blah Blub" which displays a message but like-wise only emits anything if the option is enabled.

> Dunno, doubt it, but LGPL ain't so horrible either. I just think "an
> assembler is an assembler", and "it's good enough" or whatever.

Yep, no practical reasons against it. For using it yourself, Copyleft ain't any worse.

> All the
> string and preprocessing stuff isn't as useful (to me personally).

*cough*automaticmessageandtablemaintenanceplusgeneration*cough*.

---
l

> I believe cm is using NASM 2.04+ features in his port of
> RxDOS. While I don't personally see a huge need to have a
> 16-bit NASM just to assemble that, it would still be cool

An 8086 DOS kernel done in pure ASM and compilable on 8086 would be very COOL Of course the assembler should compile from its source on 8086 and be done in pure ASM too. If done in C then it should compile on 8086 from C and also the C compiler should compile itself on DOS and 8086

> only format that definitely can't be
> used in DOS (that I know of) is Mach-O.

For 8086 development just binary and OMF are sufficient.

> Besides, I'm usually with the latest daily build of NASM.

TFM is still horrible, anyone cares ???

Arjay wrote:

> But I plan to have a test rack of some sorts again where
> I can literally quickly test stuff with a 8086, 80186, 286, 386

So you have 8086 and 80386 ? Would you occasionally do some tests maybe ?

- FreeDOS and EDR-DOS on 8086
- UI21DEB on 8086
- FreeDOS HIMEMX on 80386
- FASM on 80386
- 7-ZIP on 80386
- MPLAYER on 80486 (needs 32 MiB RAM, however)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > I believe cm is using NASM 2.04+ features in his port of
> > RxDOS. While I don't personally see a huge need to have a
> > 16-bit NASM just to assemble that, it would still be cool
>
> An 8086 DOS kernel done in pure ASM and compilable on 8086 would be very
> COOL

What about the RxDOS (GPL) hack using A86 (shareware) instead of MASM? Even Japheth compiled one tiny piece of it with JWasm. But cm's NASM fork is probably better. Then again, no expectations, I think he's just doing it for fun, no timetable.

> Of course the assembler should compile from its source on 8086 and
> be done in pure ASM too.

WASM 2.23 (Wolfware) and Venksi's ASM-1.9 are the only free/libre, 8086-compatible ones that can assemble themselves, IIRC.

> If done in C then it should compile on 8086 from C
> and also the C compiler should compile itself on DOS and 8086

TC 2.01 or TC++ 1.01 can run on 8086, but they are closed source. OpenWatcom always needs a 386+ host. (And Debian hates OSI's approval of the Sybase license.) Any of those can compile FreeDOS's KERNEL.SYS.

> > only format that definitely can't be
> > used in DOS (that I know of) is Mach-O.
>
> For 8086 development just binary and OMF are sufficient.

ELKS probably uses what BCC/Dev86 uses, AS86 (a.out?) I guess.

> So you have 8086 and 80386 ? Would you occasionally do some tests maybe ?
>
> - FreeDOS and EDR-DOS on 8086

It was only "back in the day" that FreeDOS accidentally didn't run on 8086 (boot sector). Of course, FreeCOM 0.84-pre2 needs 186+ for having all features. Old 0.82pl3 "stable" should run anywhere (even with KSSF or VSPAWN).

> - FreeDOS HIMEMX on 80386

We already know HIMEMX, as is, has a 386 bug (RayeR??), but it's not patched officially, nobody got around to it, and nobody complained.

> - FASM on 80386

Should work, why wouldn't it? I tested a few months ago on (now disconnected) 486 Sx, ran fine.

> - 7-ZIP on 80386

mik's p7zip 4.57 ran on 486 Sx fine, IIRC, later versions didn't. Haven't tested Khrusaw's latest because the machine is packed up. Anyways, HX + 7ZA always worked, IIRC.

> - MPLAYER on 80486 (needs 32 MiB RAM, however)

32 MB + data = what, 64? Unlikely that any 486 has that. I think even original Pentiums never had more than that (motherboard limit???). But if you can find a suitable test machine .... (386EX might've supported 64 MB, but who outside of NASA or whoever still has that?)

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

The assembler should be free of course. Also, the old RxDOS is bugged.

> WASM 2.23 (Wolfware) and Venksi's ASM-1.9 are the only free/libre,
> 8086-compatible ones that can assemble themselves, IIRC.

Good, but aren't they just MASM 1 clones ???

> TC 2.01 or TC++ 1.01 can run on 8086, but they are closed source.

Bad

> OpenWatcom always needs a 386+ host.

There used to be WATCOM C 16 compiler 20 years ago

> (And Debian hates OSI's approval of the Sybase license.

Not major problem for me ...

> Of course, FreeCOM 0.84-pre2 needs 186+ for having all

Considering the huge improvements in 80186

> We already know HIMEMX, as is, has a 386 bug (RayeR??), but it's not
> patched officially, nobody got around to it, and nobody complained.

Why don't those who have 80386 test it ???

> Should work, why wouldn't it? I tested a few months
> Anyways, HX + 7ZA always worked, IIRC.

Occasional retests would be good ...

> 32 MB + data = what, 64? Unlikely that any 486 has that. I think even

16 MiB EXE + 16 MiB data ( + the DeLL HeLL if HX is used )

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Arjay wrote:
> > But I plan to have a test rack of some sorts again where
> > I can literally quickly test stuff with a 8086, 80186, 286, 386
> So you have 8086 and 80386 ? Would you occasionally do some tests maybe ?
Yes, I would be happy to do occasional tests hence mention re my hardware.

> - 80486 (needs 32 MiB RAM, however)
I can't promise that I can cover 486's particularly well as from memory the only 486 I have is a 486SX not a DX. I could probably move some RAM over...

> An 8086 DOS kernel done in pure ASM and compilable on 8086 would be very
> COOL
My own long term plans include supporting as low as 8086's where possible, obviously having a few is encouragement in itself in helping to preserve them!

> (386EX might've supported 64 MB,
> but who outside of NASA or whoever still has that?)
Embedded 386's were common at one time, e.g. voicemail systems, digital cameras.
Obviously a lot of stuff is now ARM but older embedded equipment and even some newer boxes are Intel based.

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

RxDOS 7.1.5 is trash. So is A86; and it kinda defeats the purpose of using a self-recompiling assembler if you can't compile it because you lack the source code. (Actually, we don't even know whether A86 really is self-compiling.)

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

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

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

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

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

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

It's still a good answer to that statement though.

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

These are the instructions exclusive to 186+:

* POPA/PUSHA
* SHL/SHR/SAR/ROL/ROR/RCL/RCR with immediate
* ENTER, LEAVE
* Did I forget any? Yes: PUSH immediate, and some less useful: BOUND, IMUL immediate, string I/O.

Besides the ones I called less useful, you can replace all of these using simple macros. Then there's just a few things on the 8086 to be considered, like invalid opcodes not throwing Int06 and shift counts in cl ain't limited.

> and nobody complained.

How about somebody complain about it now?

---
l

> > Besides, I'm usually with the latest daily build of NASM.
>
> TFM is still horrible, anyone cares ???

Not really, it works for me. No recent instruction list with descriptions, but given that the 8086..486 instruction set doesn't change that often any more the older manual I'm using for this is just fine.

---
l

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

> > So is A86;
> Whoa! Kinda strong statement. I don't think anybody reasonably thinks A86
I agree. I think it is also worth remembering there wasn't a lot of choice when A86 was first out. For a low cost assembler it was good in its day.


>> is crap.
> It's not. But yeah, it hasn't been developed since 2000,
I can't remember exact dates but I know AWBAT (Win32 "tweak") was developed until 2003. I have a D86 here also dated 2005. Eric does still respond to emails at least to registered folks - certainly the case couple of years ago.

> the point was that A86 can run on 8086 and compile that fork of RxDOS
I think it is fair to say A86 has its downsides but also its positives. It is also nice if you want to compile simple progs without complex syntax's and yes as you've pointed out it runs on pretty much anything. Indeed I've not found anything it wouldn't run on including even "embedded" 286 typewriters !

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

> > True. Expect releases in early 2038. (In the year 2038, that is.)
> The next Y2K problem.
Don't worry there are a few before 2038.... 2010, 2011 (Y1C), 2036. Off the top of my head I also have 2017 in my mind but can't remember why/which platform. The added bonus is a number of systems were "fixed" in Y2K by as I understand it adjusting date fields "slightly" into the future in many cases 30 years=2030.

> * Nobody at Sybase probably cares anymore. Nobody seems interested. They
> don't seem to actively maintain or even ever plan to change the license.
The folks who probably knew understood it left, retired or are now senior managers who have moved away from techi work or are simply too busy elsewhere.

> So it's pretty much "dead" legally, IMHO.
Typo? I think you meant IANAL not IMHO

> Considering the huge improvements in 80186
LOL! Don't forget that the 80186 was widely used in PC's... oh wait my mistake no it wasn't ;) Probably got used in more lifts than PC's!

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

> (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!

> 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

> > Considering the huge improvements in 80186

And don't forget all the useful instructions added to the x86 instruction set with the famous 286! There's a lot of DOS software optimized for 286s! Oh wait it's the mistake of the programmers that state such non-sense, these instructions were added to the instruction set by the 186. (Because most programmers never bothered to check for the correct CPU before executing opcodes restricted to specific instruction sets, their documentation mistake doesn't hurt much anyway.) Although actual 186 chips might not have been used much in PCs, the NEC V20 and V30 had the 186 instruction set too.

---
l

> For a low cost assembler it was good in its day.

That might be true.

> It
> is also nice if you want to compile simple progs without complex syntax's

org 100h

label:
mov dx, message
mov cx, message.end - message
mov bx, 1
mov ah, 40h
int 21h

jmp short .locallabel

; The jump isn't required of course.

.locallabel:
mov ax, 4C00h
int 21h

message:
db "Now tell me this is complex syntax.",13,10
.end:

I don't doubt that you can write simple programs in A86 easily, but so can I in NASM. The difference is that NASM is better at complex programs while still allowing the simple syntax for simple stuff. (For the record, I could have called Int21.09 but I don't like it that much.)

> and yes as you've pointed out it runs on pretty much anything. Indeed I've
> not found anything it wouldn't run on including even "embedded" 286
> typewriters !

I would think running on as low as an 8086 is related to it being available for that long too. Like all I've written by now, this points to A86 being outdated.

> [...], if you believe the author.
>
> I do.

I do too. That wasn't the point.

---
l

> Now you could back up TC's alleged ability to produce small code.
whoever said this is fairly clueless. what version of TC by the way ?

> Do you
> have the necessary setup to compare a TC compile of TFK with an OpenWatcom
> compile?
we compared them loooong time ago (~2001).

TC 2.01 and TCC 1.0 produce significant larger code (I remember ~20%) then OpenWatcom, even after a lot of hand-optimizing TFK for the not very much optimizing TC

> > Now you could back up TC's alleged ability to produce small code.
> whoever said this is fairly clueless.

He himself, earlier here.

> TC 2.01 and TCC 1.0 produce significant larger code (I remember ~20%) then
> OpenWatcom, even after a lot of hand-optimizing TFK for the not very much
> optimizing TC

I thought so.

---
l

> 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??).
I NEVER said anything even remotely similar to this (and hate to be misquoted).

you might be referring to the fact that the TC kernel.sys UPXes better then the OWC kernel.sys (the TC code is still larger), where I guessed that this is probably because the TC code generator is more stupid - and as a side effect better compressable.

Firstly I don't want to get into this is better than that type of discussions particularly as I'm not a fan of any particular tool; I use what is to hand.

Still just for fun I thought I would do a quick compare using your example:


> label:
LABEL is reserved word in MASM, A86, TASM? So A86 will only compiles your program if LABEL is fixed, e.g. LABEL1. The next issue is the line length is then calculated wrong-only because A86 doesn't understand the syntax you used.

However this slightly altered version compiles fine with both A86 and NASM:


org 100h

label1:
mov dx, message
mov cx, message_end - message
mov bx, 1
mov ah, 40h
int 21h

jmp short .locallabel

; The jump isn't required of course.

.locallabel:
mov ax, 4C00h
int 21h

message:
db "Now tell me this is complex syntax.",13,10
message_end:


The above version compiles to 57 bytes with both compilers (binary match).


IMHO this is a more readable version which compiles with both (note I a recent NASM version) and is 52 bytes (binary match):

org 100h

displaymsg:
  mov dx, message
  mov ah, 9h
  int 21h
  mov ax, 4C00h
  int 21h

message:
  db "Now tell me this isn't more readable!",13,10,"$"



> I don't doubt that you can write simple programs in A86 easily,
> but so can I in NASM.
I think it is important to remember you can write complex programs in pretty much anything. Obviously most of the time it makes sense to do things the easy way if easier tools exist. There are times/people who like to do things the complex way as well though. Depending on what I'm doing I can be either!

> The difference is that NASM is better at complex programs while
> still allowing the simple syntax for simple stuff.
FYI, I have used A386 (A86's brother) to write Win32 stuff quite happily. I can't compare NASM in that regards as to be honest I've not used it for Win32.

> Int21.09 but I don't like it that much.)
Any particular reason?


> I would think running on as low as an 8086 is related to it being available
> for that long too.
Well run ability shouldn't always be assumed particularly as some boxes, e.g. CPM/bespoke systems don't boot in full IBM modes or don't have them. The typewriter I mentioned for example uses a 40x3 LCD screen which operates using A000h all the time including text modes. Obviously not easy to use ;)


> Like all I've written by now, this points to A86 being outdated.
Fully agree, thus NASM is a good choice now. Still for those of us with A86 and A86 formatted code/libraries be aware we may occasionally still use it.

> Still just for fun I thought I would do a quick compare using your
> example:

Okay, but, uhm, you do know it was supposed to be a NASM-only example?

> LABEL is reserved word in MASM, A86, TASM? So A86 will only compiles your
> program if LABEL is fixed, e.g. LABEL1.

NASM allows access to reserved words by prefixing them with '$'. That can be done automatically using macros (so that you can actually use the unprefixed word as label).

> and is 52 bytes [...]

Yup, you could write smaller code! Try this:

        mov ah, 02h
        mov dl, '!'
        int 21h
        retn

Note how this is both less source code and a smaller binary (7 byte). The source code was freed from all the unnecessary red tape. It also makes our user interface less obstructive than ever.

>   mov ah, 9h

Why not "mov ah, 9" then? This is worse than both alternatives!

>   db "Now tell me this isn't more readable!",13,10,"$"

It's not. Why is there a dollar sign behind all your messages? What's that do? I don't get it. /BLAHMODE

> > I don't doubt that you can write simple programs in A86 easily,
> > but so can I in NASM.
>
> I think it is important to remember you can write complex programs in
> pretty much anything.

How does this program look in A86? Note that here, you can add code to the installation or TSR section as necessary and all the segment arithmetic is automatically fixed up. The vstart option makes the TSR section work as a separate segment, that is, the labels there are addressed as if the section's beginning was at address 0. Besides that, note the relevant size calculations and how actually NASM isn't trying to do the segment setup here; I am doing it. Of course I usually write macros to make such complicated segment setup and access easier, this is the "unrolled" form.

        cpu 8086
        org 100h

        section TRANSIENT

transient:
        mov ah, 52h
        int 21h
        mov ax, word [ es:bx-2 ]
        push cs
        pop es
.loop:
        mov ds, ax
        inc ax
        cmp word [ 1 ], ax
        jne .next
        cmp word [ 3 ], resident_size_p
        jne .next
        mov si, 8
        mov di, residentmcb+8
        mov cx, si
        rep cmpsb
        jne .next

        push ax
        mov ax, 3521h
        int 21h
        pop ax
        cmp bx, handler
        jne .error
        mov bx, es
        cmp ax, bx
        jne .error

        push ds
        lds dx, [ 10h + handler.next ]
        mov ax, 2521h
        int 21h

        pop ds
        mov word [ 1 ], 0

        mov dx, 'U'
        jmp short .exit

.error:
        mov dx, (0FFh<<8)+'!'

.exit:
        mov ah, 02h
        int 21h

        mov ah, 4Ch
        mov al, dh
        int 21h

.next:
        add ax, word [ 3 ]
        cmp byte [ 0 ], 'M'
        je .loop

        mov ax, cs
        add ax, 10h+transient_size_p
        mov ds, ax
        mov ax, 3521h
        int 21h
        mov word [ handler.next +2 ], es
        mov word [ handler.next ], bx
        mov ah, 25h
        mov dx, handler
        int 21h

        mov ax, cs
        mov ds, ax
        add word [ residentmcb + 1 ], ax

        dec ax
        mov es, ax
        mov bl, byte [ es:0 ]
        mov ax, word [ es:3 ]

        sub ax, 10h+transient_size_p+resident_size_p+1
        mov word [ newmcb + 3 ], ax
        mov byte [ newmcb + 0 ], bl

        mov sp, $-$$+100h&~1
        mov word [ es:3 ], 10h+transient_size_p-1
        mov byte [ es:0 ], 'M'

        mov dx, 'I'
        jmp short .exit


        align 16
residentmcb:
        db 'M'
        dw 10h+transient_size_p
        dw resident_size_p
        db 0,0,0
        db "I21HOOK",0

; I'd usually do these equates in a macro
transient_size equ $-transient
transient_size_p equ transient_size+15>>4

        section RESIDENT vstart=0 align=16
resident:

handler:
        ; Do Int21 hook functionality here.
        jmp 0:0
.next:  equ $-4

resident_size equ $-resident
resident_size_p equ resident_size+15>>4

        section NEWMCB align=16
newmcb:
        db 0
        dw 0
        dw 0
        times 3+8 db 0

> Obviously most of the time it makes sense to do
> things the easy way if easier tools exist.

The easiest way (speaking of simple syntax) would be using nothing but db. That doesn't require a complex assembler either. This is an extreme comparison, but my point here is that doing things the easy way isn't what you should prefer most of the time - I usually prefer higher readability of the source code. (This doesn't mean using HLL macros to write your code for you. It means writing real code in a way so it's readable.)

> I can't compare NASM in that regards as to be honest I've not used it for
> Win32.

I've used neither for any real Win32 effort but then again it just doesn't interest me. I don't see why it would be necessary to write for a Win32 platform, DOS programs done right are complex enough.

> > Int21.09 but I don't like it that much.)
>
> Any particular reason?

It uses a dollar sign as string terminator. That is silly. (It also doesn't allow displaying device names, as they'll often contain dollar signs.)

> Obviously not easy to use ;)

Yeah.. I would assume D86 doesn't work there

> Still for those of us with A86 and A86 formatted
> code/libraries be aware we may occasionally still use it.

I never said anything against that

---
l

> Yes, I would be happy to do occasional tests hence mention re my hardware.

Thanks

1. Does your 8086 have at least 640 KiB RAM ? What floppy does it have ? 3+1/2 1.4 MiB would be cool but I doubt ...
2. How much RAM does your 80386 have ?
3. How much RAM does your 80486 have ? MPlayer needs at least 32 MiB, 7-ZIP might work with less too (if you set dict size properly)

You might get mail one day

> NASM allows access to reserved words by prefixing them with '$'. That can
> be done automatically using macros (so that you can actually use the
> unprefixed word as label).

But things like

MOV EAX, $FEDC'1234

will never work in any assembler except FASM

> * There is no real effort to port FreeDOS to any other compiler.

As there is no usable alternative ...

> But at least it tries to support FAT32 and LFN ("modern" technology)



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

Deprecate it

> It is also nice if you want to compile simple progs without complex syntax

FASM can too and very well ... just not on 8086

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> >> is crap.
> > It's not. But yeah, it hasn't been developed since 2000,
> I can't remember exact dates but I know AWBAT (Win32 "tweak") was developed
> until 2003. I have a D86 here also dated 2005. Eric does still respond to
> emails at least to registered folks - certainly the case couple of years
> ago.

AWBAT is a hack, and I don't think even EJI himself would deny that. (Uses ALINK 1.7 beta, right? BTW, that guy [A.W. in U.K.] dropped by OW's newsgroup a few months ago to talk about multi-threading.) I'm not saying it isn't good, but ... well it seemed fairly minimal when I looked years ago. (Besides, I had no interest in Windows, and not even now except compiling portable code to run there via FPC or Cygwin or similar.) Of course I would think FASM is more suitable nowadays (and with better examples, e.g. FASMW), no offense to EJI's hard work, he's very talented.

Someone told me they asked him to port A86 to Linux, but he refused. (Unreleased Isforth for DOS, ah well.)

His website still lists 4.05 as latest, so apparently he hasn't updated it officially since then (2000). IIRC, D86 had some binary patch to use 386 debug registers, which modifies the timestamp (hence your 2005 remark ??). I'm not saying you're wrong, but I don't know of any new updates or additions in past years.

---
Know your limits.h

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

Nor me, but it just means he hasn't kept it up. Granted, I personally can't help but wonder if we've "jumped the shark" on x86, adding so many things (SSSE3, SSE4.1, XOP, AVX) in addition to obvious things like FPU, MMX, SSE2, AMD64. You're right when you say A86 is dated. It's still good for lots of uses, though I don't personally use it much anymore.

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

TMA (abandoned) mimics A86 somewhat, but I don't know offhand (without trying, and I'm on the wrong computer) whether it builds with A86. Also, Octasm was originally written in A86 but now (only) assembles itself.

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

Yes, obviously I didn't mean to imply legalities. Yes, I personally think you could do whatever if you rewrite it. But I'm no lawyer (and despise legalese).

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

A lot can happen in 28 years! Looking at the past ten years, we would've never guessed computers would change so much.

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

Yes, of course, I just hate that it has a license which apparently "sucks", but nobody is around to change it or even discuss it officially.

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

It's such a bullcrap pretext. They have binary blobs, yet somehow FreeDOS is tainted?? Humbug. 99% of Linux distros aren't even FSF-labeled "free".

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

Some of the kernel devs probably knows more here than me what would need to be done. I don't honestly even remember what memory model the kernel uses. In theory, we could probably easily convert it from (non-portable) C to (non-portable) assembly for NASM, I guess. WDIS is our friend.

BCC/Dev86 is a pain to compile, so that doesn't help either. And it's pretty much the only GPL 16-bit C compiler that I know of.

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

No, I think they removed it after the TomTom incident. Last I heard, they only write the LFN, not the SFN now, but I haven't tested. (Such a dumb patent, esp. since it was for FAT, which MS hates and deprecates anyways.)

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

I didn't mean it was "better", just smaller, and obviously I couldn't remember if that was before or after UPXing (apparently only after).

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

Still?? I think they fixed that. What file / version are you looking at? But again, there are very few 8086 users still. I think Mike Chambers runs DR-DOS, and I told him to try a newer FreeDOS, and it might've worked. Perhaps SYS from 2038 fixed it, I don't remember.

> 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

Well, the point was that they couldn't share a single shell between 100% of all users. Even if 8086 users can't use it, others can (though I never need it, honestly, and originally LOADFIX for FreeDOS was a separate util anyways, so it's no dealbreaker).

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

They had both XMS and KSSF/VSPAWN variants, obviously preferring the former.

Oops, forgot that SourceForge still only has 0.82pl3. (God, they are so desparate for more volunteers or really stubborn, I dunno)! 0.84 had "too much added" without review, says Eric, including an obscure bug/hang, and even Blair never updated it "yet again" like he originally claimed (swapping, oh well).

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

I'm not even sure it builds with OpenWatcom, I forget. I know I had some minor trouble with SUPPL, so I just used a prebuilt lib for that. It's not that complicated, but it could surely be much much easier. (Centroid's DJGPP/386 shell is less compatible to MS-DOS but a thousand times easier to build. But again there was a stupid flaw where mkdir pulls in ctime unnecessarily, bloating it by several useless kb. I never properly patched that for DJGPP two years ago, and they didn't seem to care anyways. Oh well. Too much to do! I guess I'm too useless and spastic and ambitious, sorry guys.)

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

Four years (last Friday) since 1.0 release. Not a big deal, DOS ain't high priority. But yeah, we could use a bit better organization and a few volunteers. I still say we should (also) focus on DOS emulation, which is "teh futurez!"

> > For a low cost assembler it was good in its day.
>
> That might be true.

Compared to MASM or TASM.

> I would think running on as low as an 8086 is related to it being available
> for that long too. Like all I've written by now, this points to A86 being
> outdated.

Sure it's outdated. It hasn't been officially updated in ten years, it lacks anything newer than SSE1, it only runs on DOS, and it only outputs raw binary or OBJ/OMF. That's not enough these days (unless you only use DOS/OMF and don't need newer instructions). Not saying it isn't good, but admittedly it could be improved. NASM wins these days.

Part of the appeal (I think) for RxDOS was that it ran in little memory and fast, so that RxDOS could even run it too. Well, plus it was shareware, available everywhere (Simtel), unlike MASM. But RxDOS never took off, nor OpenDOS, only DOS-C because of the friendlier GPL license and C codebase (which was easier for the devs).

---
Know your limits.h

> > 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??).
> I NEVER said anything even remotely similar to this (and hate to be
> misquoted).

Long time no see!!

Sorry, I thought I paraphrased it "good enough"!

> you might be referring to the fact that the TC kernel.sys UPXes better then
> the OWC kernel.sys (the TC code is still larger), where I guessed that this
> is probably because the TC code generator is more stupid - and as a side
> effect better compressable.

Yes.

I just couldn't remember offhand if the TC code was smaller before or after UPX. I certainly didn't mean TC is "better" at codegen or output speed or anything.

---
Know your limits.h

> FASM can too and very well ... just not on 8086

I cat't remember if it has been mentioned ever, so I'll take the burden:

FASM doesn't know OMF output format, which makes it rather inadequate for DOS programming.

---
MS-DOS forever!

> But things like
>
> MOV EAX, $FEDC'1234
>
> will never work in any assembler except FASM

Face it: No one except you uses that notation

Besides, it wouldn't be that hard to add this behaviour to NASM. My assembler is freer than yours! (NASM doesn't have Copyleft.)

---
l

> I cat't remember if it has been mentioned ever, so I'll take the burden:
> FASM doesn't know OMF output format

Right.

> which makes it rather inadequate for DOS programming

NOT true (except the special case you want to mix ASM with some weird stuff like 16-bit DOS COBOL, 16-bit DOS PASCAL, 16-bit DOS C, 16-bit DOS C+++, 16-bit DOS FORTRAN, Quack-BAYSIC, ... etc)

cm wrote:

> My assembler is freer than yours!

I don't get it - explain please

> NASM doesn't have Copyleft

only Copyright ???

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > which makes it rather inadequate for DOS programming
>
> Not true (except the special case you want to mix ASMassembly with [...]).

Ahahahahahah. Or assembly. Think libraries.

> cm wrote:
>
> > NASM doesn't have Copyleft
>
> Only Copyright???

Yes, it lacks any Copyleft and only has copyright.

---
l

> Ahahahahahah. Or assembly. Think libraries

compiled from aforementioned

> Yes, it lacks any wikipedia.org/wiki/Copyleft and only has copyright.

Same for FASM. So how can NASM be more free ???

Even worse, my Copyleft stuff is Public Domain so it has already the most free license ever, impossible to beat

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Same for FASM. So how can NASM be more free???

No, FASM uses a custom "2-clause BSD with Copyleft" license. To quote the LICENSE.TXT file I found in my FASM download:

flat assembler  version 1.69
Copyright (c) 1999-2010, Tomasz Grysztar.
All rights reserved.

This program is free for commercial and non-commercial use as long as
the following conditions are adhered to.

Copyright remains Tomasz Grysztar, and as such any Copyright notices
in the code are not to be removed.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The licence and distribution terms for any publically available
version or derivative of this code cannot be changed. i.e. this code
cannot simply be copied and put under another distribution licence
(including the GNU Public Licence).

> Even worse, my Copyleft stuff is Public Domain so it has already the most
> free license ever, impossible to beat

Non-sense. Did you even read the linked article? Real Public Domain works can't be Copylefted.

---
l

> > > But yeah, it hasn't been developed since 2000, [...]
> >
> > That really doesn't bother me.
>
> Nor me, but it just means he hasn't kept it up.

Which wouldn't matter to me if it was as sophisticated as NASM or more so to begin with.

> Granted, I personally can't
> help but wonder if we've "jumped the shark" on x86, adding so many things
> (SSSE3, SSE4.1, XOP, AVX) in addition to obvious things like FPU, MMX,
> SSE2, AMD64.

It's what works with the market right now. Ask the next Itanium-based PC you see.

> Yes, obviously I didn't mean to imply legalities.

I don't see why the term "derivative" mentioned by you would apply otherwise in this context, but oh well. Probably just because that's what's on my mind right now.

> Looking at the past ten years, we would've
> never guessed computers would change so much.

But what about their evolution from 1990 to 2000? The decade before that? Computers always changed much. I'm used to it. The only thing that might have been surprising was the internet's development, although that took off in the 90ies too.

> Yes, of course, I just hate that it has a license which apparently "sucks",
> but nobody is around to change it or even discuss it officially.

Better than with DRDOS, Inc where they have refused to provide EDR-DOS with a freer license. (That they tried to sell trash made of stolen software is an entirely different story.)

> 99% of Linux distros aren't even FSF-labeled "free".

FSF isn't even what I would label "free". I don't want to primarily produce free software for its own purpose (at least, not currently). Strategically making available certain projects only with Copyleft is acceptable, and this Copylefted part of a popular distribution of course needs to be massive enough to avoid it being "stolen" for closed-source software (with the Copylefted stuff replaced). But I don't think Copyleft really is the way to go for all software, at least not in its current implementation. (The GPL is too strict as well; I would prefer LGPL (for everything). If I were to choose a license from the FSF.) I want people to copy parts of my program if it helps make their software better - no matter what license they (have to) use.

> Some of the kernel devs probably knows more here than me what would need to
> be done.

On gcc? Add 16-bit support and OMF object/.EXE/.COM output, he. On TFK? Probably not much, I assume it's portable enough that adding support for another compiler (gcc or not) wouldn't be too hard.

> I don't honestly even remember what memory model the kernel uses.

Memory models are enframing. They don't exist. Seriously: That doesn't matter much. Unless your compiler doesn't support far pointers at all you can do everything. I don't know of any compiler that does all of the (sophisticated) relocation required for a kernel, so you need to do some things on your own anyway.

> In theory, we could probably easily convert it from (non-portable) C to
> (non-portable) assembly for NASM, I guess. WDIS is our friend.

Shush, interest in kernel development is little enough as it is.

> No, I think they removed it after the TomTom incident. Last I heard, they
> only write the LFN, not the SFN now, but I haven't tested.

I think that was left as an option that defaults to off, for now.

> I didn't mean it was "better", just smaller, [...]

As the pedant I am, I have to note that you are right: TC is smaller. Its output is not

(I meant "produces smaller output" with "better" here.)

> [...] and originally LOADFIX for FreeDOS was a separate util anyways, [...]

LOADFIX is easier to implement in the shell because you don't have to hook the program loading or termination explicitly.

> 0.84 had "too
> much added" without review, says Eric, including an obscure bug/hang, and
> even Blair never updated it "yet again" like he originally claimed
> (swapping, oh well).

So yeah...

> But yeah, we could use a bit better organization

What organization?

> I still say we should (also) focus on DOS emulation,
> which is "teh futurez!"

I say someone should make a serious fork of DOSBox which makes its CPU, BIOS and DOS compatible properly, or just replaces the latter with a host file system redirector driver done right. An interface to load and access host modules (.DLL or equivalent dynamic libraries) should be provided too. They should also care for bugs and issues that don't affect any specific DOS games.

dosemu might be a better base looking at its features, but I don't think it would be easy to port that to operating systems other than Linux and/or architectures other than x86 or AMD64. (Not a big problem now, but might become one. (That is, if PCs switch to another architecture before they're powerful enough to fully emulate a current x86 machine.))

---
l

> 1. Does your 8086 have at least 640 KiB RAM ?
I have a few 8086/80186's with various specs. To be honest as it is so long since I've fired them up I don't remember their exact specs off the top of my head, however I am pretty sure the following will be fairly accurate:

1) A single 8086 laptop probably with twin 720k drives and 640k. 2) A single 8086 desktop certainly with 640k which I put it in a chip at a time :) 3) 2
RM Nimbus's 80186's 1 with a hard drive and a single 720k and the other one with twin 720k's and if my memory serves me correctly I also have 4 complete Nimbus motherboards from when I gutted 20+ of the things. I also have a rare system programmers manual and other technical information on them.
4) A single 8086 Tiny PC - basically it is a 8086 in the size of a shoe box with a single 720k drive, TV output, and was made around 1991 (i.e. late) was fairly cool compared with the crap that went on to sell later on before they went bust!

> What floppy does it have ?
Mostly on those machines 720k's. However I have I collected a few controllers and drives separately on purpose.... So I know I have at least 2 * 5 1/4" 360k full height drives, 2 * 360k half heights, 2 * 1.2, and several 720k and 1.44 drives, Basically in terms of drives I do a good line in everything except 20" 8" and newer stuff like 2.88 etc

> 3+1/2 1.4 MiB would be cool but I doubt ...
As above I can cover both :) Btw one of these days I will switch to using MiB still doesn't seem right :)

> 2. How much RAM does your 80386 have ?
I think around 4Mb possibly more as I pimped that box to run my BBS which had around 4Gb circ 1993. Again hasn't been switched on for years (in storage).

> 3. How much RAM does your 80486 have ?
32Mb I think. It was my Linux dialup gateway for years.

> MPlayer needs at least 32 MiB, 7-ZIP
> might work with less too (if you set dict size properly)
I can locate some extra RAM. Also if need be I'll free some used crap ;)

> You might get mail one day
Oh great. I used to get a lot but purposefully went quite for years. Oh dear....


> > NASM allows access to reserved words by prefixing them with '$'.
Thanks useful tip.

> FASM can too and very well ... just not on 8086
I've dabbled with FASM. Nice to have so much choice these days.

> we should focus on DOS emulation

Because ??? This will finally upgrade DOS from this absurd toy running inside Windaube to a serious participant on the OS market ??? So "we" can expect DOS versions of Firefox, Opera, Gimp, PGP/GNUPG, OpenOffice, AdobeAcrobe/Foxit/SumatraPDF, Wing-ZIP/Wing-RAR/Wing-ACE/Wing-RK, Notepad+/++/2/3, AdobePhotosh**, AutoCAD, VLC, Jawa/LimeWire, ... &Co ?

> which is " teh futurez !"

Slangy word for past 20 years ???

> Real Public Domain works can't be Copylefted.

Since they per definition must be (no Copyright)

> No, FASM uses a custom "2-clause BSD with Copyleft" license

So NASM is more free because it lacks the restriction prohibiting to switch it to the more restrictive GPL ? This is cool

Arjay wrote:

> > 3+1/2 1.4 MiB would be cool but I doubt ...
> As above I can cover both

So if I send a 3+1/2 1.4 MiB floppy (as image) you could boot it into some 8086 PC ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Real Public Domain works can't be Copylefted.
>
> Since they per definition must be (no Copyright).

Now you're either just ignorant or trolling. Read the article I linked. "Copyleft" is not the absence of copyright. Public Domain works are neither Copylefted nor copyrighted. (Technically they might be copyrighted but the copyright's owner grants you all rights, without any kind of warranty.)

> > No, FASM uses a custom "2-clause BSD with Copyleft" license
>
> So NASM is more free because it lacks the restriction prohibiting to
> switch it to the more restrictive GPL?

That's how software licensing works boy. Note that with the modified emphasis, your statement is very clear on why NASM is freer - its license is less restrictive. You are free to copy NASM's source code partly or in whole and then use that in other works (be they proprietary, GPL, or under most any other software license) with only minimal requirements. This of course doesn't mean you can enforce usage of your new version instead of the official NASM version, so you can't restrict the original this way.

I won't explain Copyleft to you too. Just look it up already!

FASM's license contributes to what is called "license proliferation", and because of the comment regarding the GPL I think that is intentional. This means, even though FASM's license is similar to the GPL with Copyleft (look it up!) and all, it is incompatible with other such Copyleft licenses. It might be interesting that technically, FASM's license might have been GPL-compatible if not for explicitly prohibiting the GPL - because distribution under the GPL's terms would insure all the requirements of the FASM license are met. The GPL would then only add restrictions, which isn't prohibited by the FASM license.

---
l

> > 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.
>
> It's such a bullcrap pretext. They have binary blobs, yet somehow FreeDOS
> is tainted?? Humbug. 99% of Linux distros aren't even FSF-labeled "free".

I don't know about binary blobs, but the Debian Free Software Guidelines say this, which might be the reason they want free compilers:

DFSG> To be free, software must be modifiable by [anyone, and they] must
DFSG> also be able to legally share modifications [...]

This probably means they want their users able to recompile everything, only using the (free) compilers that are included in the distribution.

---
l

> I don't know about binary blobs, but the
> Debian
> Free Software Guidelines say this, which might be the reason they
> want free compilers:
>
> DFSG> To be free, software must be modifiable by [anyone, and they] must
> DFSG> also be able to legally share modifications [...]
>
> This probably means they want their users able to recompile everything,
> only using the (free) compilers that are included in the distribution.

Sure, that's the reason, but it's bogus. They don't want to rebuild FreeDOS, they don't care and never have. They also couldn't care about DOSEMU either. So why pretend? Sure, OW has a weirdo license, but nobody is going to update it any time soon. If the OW hackers (who've spent years on the thing) don't care about worrying over their own work, why should I? Bah, such a mess, even if OSI approved (heh). The real problem is that nothing else (more free) can build FreeDOS, so beggars can't be choosers.

P.S. I personally think FASM is plenty free. Sure, you can't GPL it, but you couldn't realistically do that anyways with other licenses (except as a whole, which really only affects your own changes). Besides, nobody needs or wants to do so with FASM, and it's already been used commercially in many places, so it's "moot". I guess it's more of a "don't pretend you wrote it" clause than anything, so people can not be confused by different licensed derivatives. (And Japheth is right, it lacks OMF, but so does DJGPP. Besides, there are already tons of existing tools that handle that, so adding it to FASM wouldn't hurt but isn't a priority.)

---
Know your limits.h

> Sure, that's the reason, but it's bogus. [Blah]

It's bogus if you look at it from a practical viewpoint. It's not if you understand that it's a political/philosophical reason. (And though I understand them that way, I don't share their opinion.)

> Bah, such a mess, even if OSI approved (heh).

That's the fundamental difference between OSI and FSF.

> The real problem is that nothing else (more free) can build FreeDOS,
> so beggars can't be choosers.

It's Write-your-own-compiler day! If anyone cares enough about Debian.

> P.S. I personally think FASM is plenty free.

It's free - even as far as the FSF is concerned - but it's more restrictive than the actual (2- or 3-clause) BSD license. It's also a practical disadvantage to re-use the text of some other license then append a sloppy Copyleft restriction to that, this just confuses people more than an entirely (or at least, obviously visibly) custom license would have. (I won't dare suggesting to just use the GPL if you want Copyleft, heh. Ridiculous, what!)

> Sure, you can't GPL it, but
> you couldn't realistically do that anyways with other licenses (except as a
> whole, which really only affects your own changes).

What? You can GPL any 2- or 3-clause BSD licensed program all you like. (Sure, it's misconduct, but you're legally allowed to.) I don't understand what you say inside the parentheses at all.

> Besides, nobody
> needs or wants to do so with FASM, and it's already been used commercially
> in many places, so it's "moot".

It's partly a question of your philosophy (i.e. the source code is free and its freedom is "defended" (Copyleft), or the user is free), but then it's also that I feel cheated reading a 2-clause BSD license and then some lazy Copyleft notice. It's like the Sybase license thing all over again.

I also don't know why Tomasz detests the (L)GPL (alternatively, with a linking exception) like that.

> I guess it's more of a "don't pretend you wrote it" clause than anything,
> so people can not be confused by different licensed derivatives.

Why? All derivatives of BSD licensed software need to reproduce the copyright notice in the source code, documentation and other material anyway.

> And Japheth is right, it lacks OMF, but so does DJGPP.

DJGPP is a toolchain primarily intended for C development of 32-bit DPMI programs. FASM is an assembler that ostensibly supports 16-bit DOS targets. Do you see the difference? (Yes, there's an OMF 32-bit format but you don't need that for DPMI development with DJGPP because DJGPP gives you the whole toolchain for COFF anyway and 32-bit OMF isn't that widely used.)

> Besides, there are already tons of existing tools that handle that,
> so adding it to FASM wouldn't hurt but isn't a priority.

Particularly, you cannot link 16-bit DOS programs consisting of separate modules (possible created by different assemblers or compilers) with any FASM source code because the OMF format is just the 16-bit DOS object format. I mean, come on. Acceptable OMF support is even implemented in NASM, and it's so free you can just copy or adapt its code (even for "proprietary" Copyleft licensed software such as FASM).

(Okay, please just tell me you did not say the "tons of existing tools" are the reason OMF doesn't have priority for 16-bit DOS support. Because if you did say so, I would have to answer that precisely they are the reason OMF does have some priority for 16-bit DOS support.)

---
l

> > The real problem is that nothing else (more free) can build FreeDOS,
> > so beggars can't be choosers.
>
> It's Write-your-own-compiler day! If anyone cares enough about Debian.

Too hard to do, esp. since 16-bit is considered obsolete by Linux, Win32, *BSD. Heck, people are starting to say 32-bit is deprecated (eh??), as if 64-bit must kill everything else in order to justify itself (lame).

> What? You can GPL any 2- or 3-clause BSD licensed program all you like.
> (Sure, it's misconduct, but you're legally allowed to.)

How can you require someone to submit their changes without you having changed any of the code itself? I mean legally, you really think that's possible? I think you can only optionally license your own additions as GPL, which means the whole must be "GPL-compatible", right? The original bits would still remain as-is.

> > Besides, nobody
> > needs or wants to do so with FASM, and it's already been used
> commercially
> > in many places, so it's "moot".
>
> It's partly a question of your philosophy (i.e. the source code is free and
> its freedom is "defended" (Copyleft), or the user is free), but then it's
> also that I feel cheated reading a 2-clause BSD license and then some lazy
> Copyleft notice. It's like the Sybase license thing all over again.

The Sybase license is much more confusing and worse, by far.

> > I guess it's more of a "don't pretend you wrote it" clause than
> anything,
> > so people can not be confused by different licensed derivatives.
>
> Why? All derivatives of BSD licensed software need to reproduce the
> copyright notice in the source code, documentation and other material
> anyway.

But if he doesn't prevent people from not sharing their modifications, I guess he doesn't want anybody else forcing that upon them either.

> > And Japheth is right, it lacks OMF, but so does DJGPP.
>
> DJGPP is a toolchain primarily intended for C development of 32-bit DPMI
> programs. FASM is an assembler that ostensibly supports 16-bit DOS targets.

FASM is a 32-bit assembler and only runs on 32-bit, not 16-bit. It assembles itself without needing to use a linker, and in most cases it avoids such. I think only as an afterthought did Tomasz even add linkable object support. So he personally doesn't need it, so he hasn't implemented it.

> Do you see the difference? (Yes, there's an OMF 32-bit format but you don't
> need that for DPMI development with DJGPP because DJGPP gives you the whole
> toolchain for COFF anyway and 32-bit OMF isn't that widely used.)

32-bit OMF is still used somewhat (Digital Mars, OpenWatcom) but didn't Borland and MS handle it differently? So it's quite complex, which makes implementing it that much harder.

DJGPP only uses COFF in lieu of (older) a.out, esp. since GNU ld (Binutils) already had support for it. GCC and pals are heavily *nix-oriented, which means OMF isn't important to them since it's only used on x86.

> > Besides, there are already tons of existing tools that handle that,
> > so adding it to FASM wouldn't hurt but isn't a priority.
>
> Particularly, you cannot link 16-bit DOS programs consisting of
> separate modules (possible created by different assemblers or
> compilers) with any FASM source code because the OMF format is just
> the 16-bit DOS object format.

Right, because FASM wasn't designed that way, the author is only one person, he'd rather focus on other features. Plus OMF is complex, not trivial, so even if he wanted, it would take quite a while to shake out the bugs, and there truly isn't enough interest in OMF these days.

> I mean, come on. Acceptable OMF
> support is even implemented in NASM, and it's so free you can just copy or
> adapt its code (even for "proprietary" Copyleft licensed software such as
> FASM).

NASM 2.07 was first to be BSD-licensed, and it's not that old, so FASM couldn't verbatim (well, you know what I mean) borrow from it anyways until then, esp. since Tomasz prefers pure x86 assembly in lieu of C.

> (Okay, please just tell me you did not say the "tons of existing
> tools" are the reason OMF doesn't have priority for 16-bit DOS support.

It doesn't have priority to FASM's author because NASM, ArrowASM, LZASM, WASM, JWASM, Wolfware w/ macros, TASM, MASM, A86, Optasm?, etc. etc. all already support it.

> Because if you did say so, I would have to answer that precisely they
> are the reason OMF does have some priority for 16-bit DOS support.)

16-bit isn't cool anymore, so nobody cares.

> How can you require someone to submit their changes without you having
> changed any of the code itself? I mean legally, you really think that's
> possible? I think you can only optionally license your own additions as
> GPL, which means the whole must be "GPL-compatible", right? The original
> bits would still remain as-is.

No. Although you cannot change the license used by the original project (f.e. official NASM build), you can pretty much copy all their code, then license that fork as GPL. This means anyone who would then obtain their code from your fork would have to use the GPL, but anyone who got the official NASM build still would get it under their license.

The "you need to modify it" part is moot, if not generally, then because of this: I take all the NASM source code. I change file A to include 3 lines of code it did not have. I license the fork as GPL. I change file A to remove the 3 new lines. So even if anyone insisted I need to change some of the code, there's a simple workaround for that. (There are licenses that say you ain't allowed to redistribute a program with the same source code as the official build with a different license or at all, preventing this workaround. These licenses are not considered free by the FSF.)

Besides, you have to change 50+ of NASM's source files to include a different license header anyway so that's already some work there.

> The Sybase license is much more confusing and worse, by far.

True, but I still don't like the FASM license.

> But if he doesn't prevent people from not sharing their modifications, I
> guess he doesn't want anybody else forcing that upon them either.

The GPL allows you not to distribute modifications, you just mustn't distribute the binaries either. That is, anyone who gets one of your binaries (from you or someone else) has the right to get the (modified) source, but no one else.

But I see there is a valid difference here.

(Besides, you might argue that FASM's Copyleft is weak because it is not stated that combining stuff with the FASM code means that this other stuff has to be made available.)

> FASM is a 32-bit assembler and only runs on 32-bit, not 16-bit. [Blah]

Yes, I know. That's why I said "ostensibly". And "targets".

> NASM 2.07 was first to be BSD-licensed, and it's not that old, so FASM
> couldn't verbatim (well, you know what I mean) borrow from it anyways until
> then, esp. since Tomasz prefers pure x86 assembly in lieu of C.

* It was available as of the 2009-07-06 release (2.07rc1) or earlier.
* Since he would rewrite everything anyway, he could have just read their (LGPL) code or asked someone to do that to compile a documentation of the format, then implement that in FASM. This is of course moot now that the code is free.

> It doesn't have priority to FASM's author because NASM, ArrowASM, LZASM,
> WASM, JWASM, Wolfware w/ macros, TASM, MASM, A86, Optasm?, etc. etc. all
> already support it.

But that would mean these assemblers are better for some tasks than FASM. Heheheheh.

---
l

> No. Although you cannot change the license used by the original
> project (f.e. official NASM build), you can pretty much copy all
> their code, then license that fork as GPL.

I don't think so. Well, even for public domain, how could you? Their code is their code, their (original) copyright. I'm not saying I'd care or complain, but it seems backwards to re-license something you didn't write. That code should remain under the same license, it's only being compatible for the rest of the project that's legally important.

> This means anyone who would then
> obtain their code from your fork would have to use the GPL,
> but anyone who got the official NASM build still would get it under their
> license.

I doubt it. Besides, BSD vs. GPL ... GPL loves BSD, but BSD hates GPL, so nobody would prefer GPL except diehards, esp. if it was only blindly re-licensed and not by original authors / copyright holders. (Honestly I wonder why anybody cares AT ALL about stupid licenses, they are so boring! Code is code, why is it so hard for people to share and accept?)

> The "you need to modify it" part is moot, if not generally, then because of
> this: I take all the NASM source code. I change file A to include 3 lines
> of code it did not have. I license the fork as GPL. I change file A to
> remove the 3 new lines. So even if anyone insisted I need to change some of
> the code, there's a simple workaround for that.

I don't think that would count. Even though in theory you should be able to extract the original, in practice it's not always easy. But they could always just get the original anyways, assuming they knew that it existed (and where to grab it).

EDIT: I think GCC will allegedly accept 20 lines or less without copyright assignment but nothing greater.

> (There are licenses that
> say you ain't allowed to redistribute a program with the same source code
> as the official build with a different license or at all, preventing this
> workaround. These licenses are not considered free by the FSF.)

The FSF also dislikes clauses preventing non-commercial use, and yet I've seen a few "GPL" apps add that restriction.

> Besides, you have to change 50+ of NASM's source files to include a
> different license header anyway so that's already some work there.

Well, the functionality stays the same. Truly, I honestly think (legally) you're only allowed to re-license your own changes. I think the "whole" of the project can be GPL even if 99% is BSD licensed.

(But I'm no lawyer though I'll admit I don't care what they think, they can invent any crazy idea, and it's insane to pretend I'll just comply blindly to whatever some crackpot can come up with. Different countries have different laws anyways, so there's no pleasing everybody.)

> > The Sybase license is much more confusing and worse, by far.
>
> True, but I still don't like the FASM license.

Why, because you can't re-license it (do you really want to??) or because it's "yet another" license that the world didn't need? The world doesn't truly "need" FASM, but it's a truly awesome tool, a good compliment to NASM, IMHO.

> (Besides, you might argue that FASM's Copyleft is weak because it is not
> stated that combining stuff with the FASM code means that this other stuff
> has to be made available.)

I don't think Tomasz intends to restrict anyone from doing anything with it, including proprietary changes, which would indeed not work if it was GPL. (However, AFAICT, nobody has made any sizable changes to it except for Fresh, FASMARM, Wink ... and you can easily live without any of that).

> > FASM is a 32-bit assembler and only runs on 32-bit, not 16-bit. [Blah]
>
> Yes, I know. That's why I said "ostensibly". And "targets".

In other words, 32-bit was the initial mindset, even if he did / does love DOS and DOS Navigator heavily.

> > NASM 2.07 was first to be BSD-licensed, and it's not that old, so FASM
> > couldn't verbatim (well, you know what I mean) borrow from it anyways
> until
> > then, esp. since Tomasz prefers pure x86 assembly in lieu of C.
>
> * It was available as of the 2009-07-06 release (2.07rc1) or earlier.
> * Since he would rewrite everything anyway, he could have just read their
> (LGPL) code or asked someone to do that to compile a documentation of the
> format, then implement that in FASM. This is of course moot now that the
> code is free.

Honestly, I think he has looked at NASM before, but obviously he's rewritten everything to suit his own ways of doing things (different macros, always did opcode size reduction similar to YASM, different algorithms).

> > It doesn't have priority to FASM's author because NASM, ArrowASM, LZASM,
> > WASM, JWASM, Wolfware w/ macros, TASM, MASM, A86, Optasm?, etc. etc. all
> > already support it.
>
> But that would mean these assemblers are better for some tasks than FASM.
> Heheheheh.

Yes, of course, since there are too many object and executable formats out there, and no one assembler or linker supports them all (though NASM tries pretty hard). Clearly Tomasz has no problem writing apps (DOS, Win32, Linux) completely in pure assembly. It shouldn't be that surprising.

> I don't think so. Well, even for public domain, how could you? Their code
> is their code, their (original) copyright.

But they allow you to redistribute and modify it as you wish. As for Public Domain (which isn't exactly the same as 2-clause BSD): that would mean no copyright applies, so you're free to do everything you want with it, even some things (i.e. removing the copyright/origin statements) you ain't allowed with any BSD license.

> I'm not saying I'd care or
> complain, but it seems backwards to re-license something you didn't write.
> That code should remain under the same license, it's only being compatible
> for the rest of the project that's legally important.

The point was that it's allowed. If that is the case, it doesn't mean it makes sense!

> I doubt it. Besides, BSD vs. GPL ... GPL loves BSD, but BSD hates GPL, so
> nobody would prefer GPL except diehards, esp. if it was only blindly
> re-licensed and not by original authors / copyright holders.

That's why I mentioned it in the example - although there's no Copyleft with the BSD licenses, you still can't "revoke" the freedom users get from other (here: the original) distributors.

Besides, it's the other way around: BSD loves everyone, and it allows everyone to copy the program under whatever license. GPL is a lot more picky

> (Honestly I
> wonder why anybody cares AT ALL about stupid licenses, they are so boring!
> Code is code, why is it so hard for people to share and accept?)

's what I say. It's also the reason I prefer (2-clause) BSD for the stuff I write - everyone should be happy to use it instead of worrying about their license, whether they're in a business or FSF zealots. I don't like the GPL's viral nature, so I won't spread it more if I have the choice not to.

Of course, choosing BSD for my stuff also has the practical advantage that I can switch to GPL whenever I feel like it, even if others have contributed to my (BSD) code base. Not that I anticipate that to happen. (Me feeling like changing to GPL, or contribution to my code base, you ask? Probably both.)

> Even though in theory you should be able to extract the original, in
> practice it's not always easy.

What? That example was to show how to work around your "need to change something"; I would specifically create a fork to carry that out, not use some existing one.

> But they could
> always just get the original anyways, assuming they knew that it existed

As I said, that's what the point of this whole exercise was. You certainly can redistribute a fork of a (2-/3-clause) BSD project under the GPL, but unless you improved it so much that people had a reason to prefer your fork, they wouldn't have to prefer it.

> EDIT: I think GCC will allegedly accept 20 lines or less without copyright
> assignment but nothing greater.

Really? That would be ridiculous, especially from the GNU zealots that talk about freedom all the time. If I want to write a source code file without any copyright notices, free tools should allow me to do that! (It's also a question of privacy - the tools should not scan my data for such things at all.)

> The FSF also dislikes clauses preventing commercial use, and yet I've
> seen a few "GPL" apps add that restriction.

Yep, thus are people. Legally, these applications of course ain't compatible with the GPL, they (so to say) use a non-GPL license based on the GPL.

> Truly, I honestly think (legally)
> you're only allowed to re-license your own changes.

No. Whether re-licensing work you don't "own" is ethical is an entirely different question - but I'm pretty sure it's legal. IANAL either, so we would have to ask, like, the FSF for a more definitive answer.

> I think the "whole" of
> the project can be GPL even if 99% is BSD licensed.

That is true, but only if you keep track of what is available as BSD and what is not and if you inform the receiver (ie user) about the fact that these parts are still available under BSD. Otherwise, they ain't allowed to "extract" the BSD code again, even if they know which parts these are. (Practically, if they know that although the whole project is exclusively licensed as GPL now, they'll usually have access to the original code anyway so it doesn't matter.)

> But I'm no lawyer though I'll admit I don't care what they think, they can
> invent any crazy idea, and it's insane to pretend I'll just comply blindly
> to whatever some crackpot can come up with.

The BSD and GPL licenses make perfect sense to me.

> Why, because you can't re-license it

Because it's less free. NASM is freer. That's where we started, remember?

> (do you really want to??)

No.

> or because it's "yet another" license that the world didn't need?

Yes, that too.

> The world doesn't truly "need" FASM,

Quoting that out of context might not AMUSE some

> but it's a truly awesome tool, a good compliment to NASM, IMHO.

I don't know. True, there's a few things that FASM can do but NASM can not. NASM, in turn, is freer and more portable.

> I don't think Tomasz intends to restrict anyone from doing anything with
> it, including proprietary changes, which would indeed not work if it was
> GPL.

Is proprietary adaptation really allowed by that license? It says not to redistribute FASM code under any other license. Although it has the loophole that you can distribute only binaries (i.e. make the code base proprietary), you still would have to use the FASM license for your source. That means you wouldn't be allowed to combine the source with any other source code that has a license conflicting with FASM's. (For example, suppose there is a program FOO which has a license very similar to FASM's. Now you wouldn't be allowed to combine FOO's and FASM's source code, because both require all source code to use their license.) This is a practical problem, because no company would risk to violate the license like that even though arguably it would be hard to prove from the outside (when they only distribute binaries).

True, the GPL doesn't allow proprietary adaptation, but I don't think FASM's license does either. Whether that's intentional I don't know.

> Honestly, I think he has looked at NASM before, but obviously he's
> rewritten everything to suit his own ways of doing things (different
> macros, always did opcode size reduction similar to YASM, different
> algorithms).

The point was that he could now (and even before) implement OMF support by using NASM's low-level implementation as reference. Assembler syntax doesn't come into this.

---
l

> > EDIT: I think GCC will allegedly accept 20 lines or less without
> copyright
> > assignment but nothing greater.
>
> Really? That would be ridiculous, especially from the GNU zealots that talk
> about freedom all the time. If I want to write a source code file without
> any copyright notices, free tools should allow me to do that! (It's also a
> question of privacy - the tools should not scan my data for such things at
> all.)

Sorry, didn't mean to confuse you. No, I meant the GCC devs (on behalf of FSF?) won't accept any contributions to the compiler itself without copyright attribution, but I think they don't need it for trivial code that is 20 lines or less.

> > But I'm no lawyer though I'll admit I don't care what they think, they
> can
> > invent any crazy idea, and it's insane to pretend I'll just comply
> blindly
> > to whatever some crackpot can come up with.
>
> The BSD and GPL licenses make perfect sense to me.

I meant lawyers and their crazy (constantly changing and new) laws. There's no way to please them across the board. It's just insane to pretend I can even understand their ideas, much less would be willing to comply (at a loss) at every random decision they make. I'm not trying to be a bastard, but they can't just say whatever they want and get away with it.

> > The world doesn't truly "need" FASM,
>
> Quoting that out of context might not AMUSE some

Well, let's be honest, how many assemblers does one person need? I can name at least 30 for x86, and that's surely more than I need! I could maybe live exclusively off of NASM, YASM, FASM, JWASM, or OCTASM if I had to. Some people seem to only use GAS (blech). Well, okay, it truly depends on OS and compiler support that my projects use, etc, but you get the idea: there are (too) many! Doesn't mean somebody can't write yet another with some innovative ideas (like OCTASM or SolarASM or even FASM did).

> > but it's a truly awesome tool, a good compliment to NASM, IMHO.
>
> I don't know. True, there's a few things that FASM can do but NASM can not.
> NASM, in turn, is freer and more portable.

NASM is cool, but it has few true advantages over FASM, esp. for my needs. Then again, I'm just a hobbyist, just a lame hacker. I do like both a lot, though, truly.

> > I don't think Tomasz intends to restrict anyone from doing anything with
> > it, including proprietary changes, which would indeed not work if it was
> > GPL.
>
> Is proprietary adaptation really allowed by that license? It says not to
> redistribute FASM code under any other license. Although it has the
> loophole that you can distribute only binaries (i.e. make the code base
> proprietary), you still would have to use the FASM license for your source.
> That means you wouldn't be allowed to combine the source with any other
> source code that has a license conflicting with FASM's. (For example,
> suppose there is a program FOO which has a license very similar to FASM's.
> Now you wouldn't be allowed to combine FOO's and FASM's source code,
> because both require all source code to use their license.) This
> is a practical problem, because no company would risk to violate the
> license like that even though arguably it would be hard to prove from the
> outside (when they only distribute binaries).
>
> True, the GPL doesn't allow proprietary adaptation, but I don't think
> FASM's license does either. Whether that's intentional I don't know.

To be honest, I'm not sure, but he said something recently that sounded like he didn't care what somebody did with their changes (e.g. Wink). Plus there's the (recently updated) FASM DLL, which makes it even easier to use in proprietary apps. (I think PureBASIC just uses the FASM.EXE directly, though.)

> > Honestly, I think he has looked at NASM before, but obviously he's
> > rewritten everything to suit his own ways of doing things (different
> > macros, always did opcode size reduction similar to YASM, different
> > algorithms).
>
> The point was that he could now (and even before) implement OMF support by
> using NASM's low-level implementation as reference. Assembler syntax
> doesn't come into this.

He's already said it's pretty complex to do correctly, and it's clearly low priority as he was quite busy with real life (PhD?) for a long time. Also, like I said, there are other assemblers who already do it, hence probably why GAS and YASM also still don't support it. Face it, old closed source 16-bit OBJ libs are rare these days, esp. considering how far Linux and *BSD have come pretty much reimplementing everything from scratch. (But honestly, he is going to implement Mach-O support soon, so I guess adding yet another format isn't too far from his mind.)