DOS ain't dead

As I wrote in other thread @ , I studied/debugged DPMILD32 a bit and found several things that "leave space for improvements" :

- Avoid loading DPMIST32.BIN . How ?

If executable is not supported by DPMILD32, and size is $180...$280 bytes, search it for "find loader DPMILD" and "from loading overlay", and if both are found, just ignore it instead loading

-
;*** if the loader is loaded as overlay (by DPMIST32.BIN)
;*** DS:DX will point to full path of DPMILDXX.EXE
;*** and DS:BX will have path of program to load
;*** (bad design, but cannot be changed anymore)

What exactly is bad design here ?

- Seems DPMILD32 (and also DPMILD32.BIN, and even HDLD32.BIN) do unconditionally support 32-bit NE, while PE is optional
- - Is the 32-bit NE useful at all ? Maybe it could get kicked
- - Seems that for a PE, DPMILD32 (if PE-enabled at all) first tries a NE (open file, read $40 bytes, test for MZ, read next EXE position at $3C, seek (and fail ) , read, compare against "NE", close file), and then retries with PE (reopen and repeat all the fun). This could be optimized at least
- - NE code is hard-merged into main module, PE is separate - probably could be better also ...

- Spawning still doesn't work at all, see shot:



Fails with CC386 as well as with FreeBASIC

What's wrong here ?

- Don't enable the LONG MODE

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

> - Seems DPMILD32 (and also DPMILD32.BIN, and even HDLD32.BIN) do
> unconditionally support 32-bit NE, while PE is optional

Yes.

> - - Is the 32-bit NE useful at all ? Maybe it could get kicked
> - - Seems that for a PE, DPMILD32 (if PE-enabled at all) first tries a NE
> (open file, read $40 bytes, test for MZ, read next EXE position at $3C,
> seek (and fail ) , read, compare against "NE", close file), and then
> retries with PE (reopen and repeat all the fun). This could be optimized at
> least
> - - NE code is hard-merged into main module, PE is separate - probably
> could be better also ...

NE support was first.

I'm not sure if it is worth to analyze DPMILD32 too deeply. There will be a significant change in next hx: a simplified PE loader stub - LOADPE.BIN, size just 1.25 kB. This stub will make DPMILD32.EXE obsolete for 32bit DOS applications which don't need dll support ... which are virtually all.

> - Spawning still doesn't work at all, see shot:
>
> Fails with CC386 as well as with FreeBASIC
>
> What's wrong here ?

DPMILDR=8 prevents DPMILD32 from trying to load another application, but it doesn't tell HDPMI32 to supply separate address spaces for clients. Therefore you either

a) must supply base relocations with your PE binary ("/FIXED:NO") or
b) set HDPMI=32 to tell HDPMI to supply separate address spaces.

---
MS-DOS forever!

> I'm not sure if it is worth to analyze DPMILD32 too deeply. There will be
> a significant change in next hx: a simplified PE loader stub - LOADPE.BIN,
> size just 1.25 kB. This stub will make DPMILD32.EXE obsolete for 32bit DOS
> applications which don't need dll support ... which are virtually all.

Very good news Also HDLDPE32.BIN with HDPMI32 built-in ?

This is very good for new DOS development, but won't really make DPMILD32 obsolete: for Win32 emulation, one still needs the DLL hell Thus, it might be "worth" to analyze DPMILD32 "too deeply" nevertheless ... and the questions of spawning, NE usefulness, and protection from TripleFault'ing remain open ... plus the long mode

> DPMILDR=8 prevents DPMILD32 from trying to load another application, but
> it doesn't tell HDPMI32 to supply separate address spaces for clients.

> a) must supply base relocations with your PE binary ("/FIXED:NO")

Not useful for existing Win32 stuff, since this pretty never has fixups

> or
> b) set HDPMI=32 to tell HDPMI to supply separate address spaces.

Works



In other forum you mentioned DPMILDR=8 only, so I missed the HDPMI=32

But still, it might be a good idea to have spawning working without those hacks ...

1. DPMILDR=8 : but why not suppress this hack, check for address space & fixups, and load into same if possible, and into a new one otherwise ?

2. HDPMI=32 : OK, making this the default would hog low memory But I have an other idea:

In Win32 there is true multitaxing, you can have 1'000'000 tasks, every of them has its private throne at $400000, and the space gets switched on every task switch (?), and the DLL hell ... no idea how to share it then

Anyway, in DOS there is no true multitaxing, just spawning, A spawns B, thus A is suspended while B is running, when B has done, A resumes ... and the obvious (or did I miss something ?) solution arises: when A spawns B, just allocate a memory block with size of A at highest free / some high and free address, move A there, free the famous throne at $400000, load B into there, run B, and when B has done just move A back and resume it

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

> In other forum you mentioned DPMILDR=8 only, so I missed the HDPMI=32

It's explained very lengthy in COMPAT.TXT ...

> 1. DPMILDR=8 : but why not suppress this hack, check for address space &
> fixups, and load into same if possible, and into a new one otherwise ?

I can't remember the reasons, but there WERE strong reasons why this didn't work. If you can supply a working patch ...

> 2. HDPMI=32 : OK, making this the default would hog low memory

It's not just the memory. It's simply not DPMI 0.9 compatible, would make DPMI v0.9 TSRs impossible. And one of my favorite toys - debxxf - also runs as separate client and wants direct access to the debuggee's memory, IDT and LDT.

> Anyway, in DOS there is no true multitaxing, just spawning, A spawns B,
> thus A is suspended while B is running, when B has done, A resumes ... and
> the obvious (or did I miss something ?) solution arises: when A spawns B,
> just allocate a memory block with size of A at highest free / some high
> and free address, move A there, free the famous throne at $400000, load B
> into there, run B, and when B has done just move A back and resume it
>

Yes, that's possible, but is just another hack. For Win32 programs, the HDPMI=8 "hack" is preferable IMO since it is very stable and, more important, this appproach will finally allow to run several clients/tasks concurrently. Some Win32 applications need that (i.e. CygWin).

---
MS-DOS forever!

> It's explained very lengthy in

Not very lengthy, but it is

> I can't remember the reasons, but there WERE strong reasons why this
> didn't work. If you can supply a working patch ...

OK ... you probably know that there is for "external" people no easy way to write, and even less to compile a potential patch ... and submitting an untested one is not significantly safer than submitting random garbage

> > 2. HDPMI=32 : OK, making this the default would hog low memory
> It's not just the memory. It's simply not DPMI 0.9 compatible, would make
> DPMI v0.9 TSRs impossible. And one of my favorite toys - debxxf - also
> runs as separate client and wants direct access to the debuggee's memory,
> IDT and LDT.

Thus you are confirming that HDPMI=32 is a bad hack

> Yes, that's possible, but is just another hack.

Yeah ... is there a piece of code that is NOT a hack anywhere in the universe ? Adding my "hack" would be a great improvement of HX

> For Win32 programs, the HDPMI=8 "hack"

HDPMI=32 and DPMILDR=8 ?

> is preferable IMO since it is very stable

Yeah ... I didn't ask for "disabling" it ...

> and, more important, this appproach will finally allow

In future, not yet ?

> to run several clients/tasks concurrently.
> Some Win32 applications need that (i.e. CygWin).

Thus true multitasking ? For doing what ? Compiling ?

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

> OK ... you probably know that there is for "external" people no easy way
> to write, and even less to compile a potential patch ...

It's not "easy", but it is very well possible ... and it was done several times already. Just improve your skills (hint: evil FASM syntax won't be accepted, good MASM is prefered).

> Thus you are confirming that HDPMI=32 is a bad hack

No, nonsense!

> Yeah ... is there a piece of code that is NOT a hack anywhere in
> the universe ? Adding my "hack" would be a great improvement of HX

IMO no.

> > and, more important, this appproach will finally allow
> In future, not yet ?

Not yet. Win32 CygWin and MinGW don't work with current HX, they need multi-tasking. However, this issue has low priority.

---
MS-DOS forever!

> > > and, more important, this appproach will finally allow
> > In future, not yet ?
>
> Not yet. Win32 CygWin and MinGW don't work with current HX, they need
> multi-tasking. However, this issue has low priority.

But HX does fully support multi-threading, yes?

> Anyway, in DOS there is no true multitaxing, just spawning,

There are some DOSes which have "true" multitasking: f.e. Dr-DOS 7.03 has co-operative multitasking.

> But HX does fully support multi-threading, yes?

I don't know if it is "fully", but "to some extent" - yes.

---
MS-DOS forever!

> > But HX does fully support multi-threading, yes?
>
> I don't know if it is "fully", but "to some extent" - yes.

Ok, you knew this was coming..

Just what does "to some extent" mean exactly. I've just read that "changing a threads priority may not make any difference". May not? Please elaborate.

Also:

Does HX implement priority boosting?
How does it handle file I/O and other DOS calls?
What is the timeslice, and can it be changed?
Does a complete timeslice have to have elapsed before a context-switch can occur?
What timer does it use - the PIT#0 or the RTC interrupt?
Can an application reprogram PIT#0 without it screwing up the task scheduler?

> Just what does "to some extent" mean exactly.

"to some extent" means: "to a certain extent" (sorry for my bad English )

Thread priorities aren't supported, but "SetThreadPriority()" isn't a no-op, because changing a thread's priority to "real-time" will have "some" impact - IIRC.

> Does HX implement priority boosting?

There is some code suggesting that it is implemented, but it is almost 12 years old and I doubt it will survive a review - therefore I don't even try.

> How does it handle file I/O and other DOS calls?

It calls int 21h with register AX set "properly".

When the "indos" flag is set, no thread switching is done.

> What is the timeslice, and can it be changed?

it is 20 ms and it can be changed in the source.

> Does a complete timeslice have to have elapsed before a context-switch can
> occur?

"Usually" yes.

> What timer does it use - the PIT#0 or the RTC interrupt?

The RTC - "usually" (that is, it can optionally be changed to use the PIT timer).

> Can an application reprogram PIT#0 without it screwing up the task
> scheduler?

The scheduler might not be worried too much. But why should a Win32 program come to think that it can "reprogram" the hardware?

---
MS-DOS forever!

> > Just what does "to some extent" mean exactly.
>
> "to some extent" means: "to a certain extent" (sorry for my bad English
> )

It's not bad English, just ambiguous.

> Thread priorities aren't supported, but "SetThreadPriority()" isn't a
> no-op, because changing a thread's priority to "real-time" will have
> "some" impact - IIRC.

Ok.

> > How does it handle file I/O and other DOS calls?
>
> It calls int 21h with register AX set "properly".
>
> When the "indos" flag is set, no thread switching is done.

Right, so DOS calls are effectively serialized.

> > What is the timeslice, and can it be changed?
>
> it is 20 ms and it can be changed in the source.

But not programatically.

> > Does a complete timeslice have to have elapsed before a context-switch
> can occur?
>
> "Usually" yes.



> > What timer does it use - the PIT#0 or the RTC interrupt?
>
> The RTC - "usually" (that is, it can optionally be changed to use the PIT
> timer).

Ok.

> > Can an application reprogram PIT#0 without it screwing up the task
> > scheduler?
>
> The scheduler might not be worried too much. But why should a Win32
> program come to think that it can "reprogram" the hardware?

Why would a DOS program think it can't?

Is it your only goal to [partially] emulate Windows, or does HX aspire to be capable of being used for some things that Windows can't?

Hope Japheth won't get too angry if I invade here in ...

Jaybur wrote:

> But not programatically.

> > "Usually" yes.
>

> > The scheduler might not be worried too much. But why should a Win32
> > program come to think that it can "reprogram" the hardware?
>
> Why would a DOS program think it can't?
>
> Is it your only goal to [partially] emulate Windows, or does HX aspire to
> be capable of being used for some things that Windows can't?

Maybe there is a confusion here what HX can and what not ...

HX definitely can do things that "Windows" can't - support native DOS applications without any Win32 API

Thus you might have to make a choice whether you want to create:

- A Win32 application, working in DOS via HX also

-> No DOS or BIOS calls, no hardware access, no VGA/VESA, use API and DR-DRAW instead

or

- A native DOS application. Then you can use all known DOS/DPMI features, but no importing from DLL's, OTOH possibility to link-in (but with Delphi ???) some "statical" versions of the API ? :?

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

> improve your skills

Good idea But won't fix the main problem: I don't have a compiler

> hint: evil FASM syntax won't be accepted, good MASM is prefered

OK ... confirming receipt of hint, now supply evidence of evil please

> > Thus you are confirming that HDPMI=32 is a bad hack
> No, nonsense!

If it was good and safe it would be the default

> CygWin and MinGW don't work with current HX, they need multi-tasking.

Output code works, compiler not ?

> However, this issue has low priority.

I don't need it badly. Just we know what "compiler support" means ...

Still, I have no idea why a compiler needs full multitasking

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

> Maybe there is a confusion here what HX can and what not ...
>
> HX definitely can do things that "Windows" can't - support native DOS
> applications without any Win32 API
>
> Thus you might have to make a choice whether you want to create:
>

> - A Win32 application, working in DOS via HX also
>
> -> No DOS or BIOS calls, no hardware access, no VGA/VESA, use API
> and DR-DRAW instead
>
> or
>
> - A native DOS application. Then you can use all known DOS/DPMI features,
> but no importing from DLL's,

Well I would like to use a hybrid system where the HX Windows emulator provides "extra DPMI functionality" by emulating (some of the) known and documented Win32 API calls.

That is, A DPMI program with extensions provided by Japheths Win32 emulator.
Is that such a bad idea?

> OTOH possibility to link-in (but with Delphi ???) some "statical" versions of the API ? :?

I could write a custom Delphi RTL, but that would be defeating the object because I want to write an application framework that will detect what environment it is running under (DOS/DPMI or Win32) and act accordingly. The same .exe would be able to be run either as a DPMI app or as a native Windows app. But DOS/DPMI is the deployment target because there are things that Windows can't do, such as realtime. Since limited pseudo-realtime functionality can be emulated under Windows by carefully controlling the Windows environment (during GV32 application development), it is likely to be possible to do the vast majority of GV32 application development work under Windows and the Delphi IDE and debugger, with just the final part of testing done under DOS/DPMI.

[edit] Swapped quotes and replies around - they were the wrong way around.

> > - A native DOS application. Then you can use all known DOS/DPMI features,
> > but no importing from DLL's,

No, the "dll importing" was intentionally separated from the Win32 emulation to make it available for true DOS applications as well (see DPMILD32.TXT).

> Well I would like to use a hybrid system where the HX Windows emulator
> provides "extra DPMI functionality" by emulating (some of the) known and
> documented Win32 API calls.
>
> That is, A DPMI program with extensions provided by Japheths Win32
> emulator.
> Is that such a bad idea?

No, I wrote some small apps which are "hybrid". And IIRC it's mentioned in the docs that it is possible.

However, there are at least 2 catches with this approach:

- it's not documented in detail what resources are reserved for the Win32 emulation layer. If you're using your brain and read DKRNL32.TXT, you will possibly find out most of it, though.

- the win32 emulation might be increased and use hardware which currently is "free" (implementing the serial COMM API for example), thus breaking an existing "hybrid" application which accessed this hardware directly.

These are no severe restrictions and if you link the Win32 emulation statically or use your "private" version of DKRNL32.DLL, the second catch will even become a non-issue.

---
MS-DOS forever!

> Good idea But won't fix the main problem: I don't have a compiler

POASM

> OK ... confirming receipt of hint, now supply evidence of
> evil please

they're evil because they force me, the innocent user, to use square brackets for accessing variables. And the '[' and ']' are very hard to type in on German keyboards.

> If it was good and safe it would be the default

No. It's similiar to the difference of DPMI v0.9 and DPMI v1.0 hosts. Some things can't work with DPMI v1.0 anymore. Sometimes new things have to "break" compatibility, you know?

> Still, I have no idea why a compiler needs full multitasking

It isn't "the compiler", but CygWin and MinGW want to provide a full environment with shell, make, gcc and this other lunix crap.

---
MS-DOS forever!

> These are no severe restrictions and if you link the Win32 emulation
> statically or use your "private" version of DKRNL32.DLL, the second catch
> will even become a non-issue.

So as you say, no show-stoppers at all. And if you put conditional defines around the various parts of the Windows emulation (maybe you already have), then I could keep up with the latest and greatest HX DLL's, and just [un]define and reassemble anything that isn't wanted for GV32.

The only major problems I see ATM are HX's rudimentary task-scheduler, and maybe some imports required by the Delphi RTL code that DKRNL32.DLL or the other Win32 DLL's don't support, but I won't know about those (if any) for a while yet.

> > Good idea But won't fix the main problem: I don't have a compiler
> POASM

Thanks ... but doesn't work for me



1. No POASM package exists ... only almost 10 MiB of full PellesC
2. No archive available, only "installer", 32-bit (thanks God not yet fully dropped in favor of 64-bit)
3. PO-Installer (Hacked NSIS ? ) doesn't extract with 7-ZIP nor anything else ... and doesn't run on anything except Vi$ta and XP ... had to abuse someone's Vi$ta PC to get the console files out
4. None of the files works
5. Seems that POASM supports only COFF for output (while FASM also supports MZ, PE, and "raw binary"), and POASM supports use32 only (besides xxx-64 and "ARM") (while FASM supports use16 also)

Very hard to avoid ^^^ conclusion that POASM sucks considerably more than FASM

> they're evil because they force me, the innocent user, to use square
> brackets for accessing variables.

YES, but MASM also uses them ... the difference is that FASM has consistent rules for bracketing, while MASM seems not to have any ... of course I might be wrong again, but then many other people whining about the same thing would be wrong also

> And the '[' and ']' are very hard to type in on German keyboards.

YES, but "argument" doesn't work:
1. MASM also uses [] (less ?)
2. MASM uses many other evil characters ()<>?|@& that are very hard to type, and you can't use DOS anymore, because you can't type "\"
3. You can't use JZ/JNZ either - they would translate into JY/JNY
4. Just avoid loading of "German keyboard driver" (I never use such stuff, exactly 0 bytes is ways too bad for me ) or German versions of Windaube

> No. It's similiar to the difference of DPMI v0.9 and DPMI v1.0 hosts. Some
> things can't work with DPMI v1.0 anymore. Sometimes new things have to
> "break" compatibility, you know?

YES. Then this seems to be the most crucial difference between DPMI 0.9 and 1.0

> It isn't "the compiler", but CygWin and MinGW want to provide a full
> environment with shell, make, gcc and this other lunix crap.

Executables coming from MinGW and CygWIN (need CYGWIN1.DLL - only 2 MiB) do work with HX ...

... thus GCC/AS/LD do work also , just the "IDE" doesn't ?

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

> 5. Seems that POASM supports only COFF for output (while FASM also
> supports MZ, PE, and "raw binary"), and POASM supports use32 only (besides
> xxx-64 and "ARM") (while FASM supports use16 also)
>
> Very hard to avoid ^^^ conclusion that POASM sucks considerably more than
> FASM

Agreed. I'm not in the mood to defend this thing. It once was rather promising ...

> YES, but MASM also uses them ... the difference is that FASM has
> consistent rules for bracketing, while MASM seems not to have any ... of
> course I might be wrong again, but then many other people whining about
> the same thing would be wrong also

"one million flies ..."

But yes, I also sometimes see people complaining about MASM's "bracket rules". Usually these are ASM noobees (a rather annoying species IMO) who don't know the difference between a variable and the address of a variable.

> > It isn't "the compiler", but CygWin and MinGW want to provide a full
> > environment with shell, make, gcc and this other lunix crap.
>
> Executables coming from MinGW and CygWIN (need CYGWIN1.DLL - only 2 MiB)
> do work with HX ...
>
> ... thus GCC/AS/LD do work also , just the "IDE" doesn't ?

Yes, but without the "IDE" it's impossible to MAKE a project.

---
MS-DOS forever!

> > ... thus GCC/AS/LD do work also , just the "IDE" doesn't ?
>
> Yes, but without the "IDE" it's impossible to MAKE a project.

Who needs an IDE?

---
Forum admin

> > OK ... confirming receipt of hint, now supply evidence of
> > evil please
>
> they're evil because they force me, the innocent user, to use square
> brackets for accessing variables. And the '[' and ']' are very hard to
> type in on German keyboards.

What editor do you use? You can usually set up a "pseudo macro" (or map or abbrviation or digraph or whatever) to do what you want. Most decent editors also allow you to config all the keys.

> What editor do you use? You can usually set up a "pseudo macro" (or map or
> abbrviation or digraph or whatever) to do what you want. Most decent
> editors also allow you to config all the keys.

Thanks! But then, I have no problem with FASM because I don't use it (IMO only MASM and NASM are generally usable tools in professional quality).

For the FASM adorers I have a riddle to solve. See

http://board.flatassembler.net/topic.php?t=8338

It's a trivial task for all assemblers - with FASM as the one exception apparently.

---
MS-DOS forever!

> Who needs an IDE?

I don't know. Didn't you notice the quotes? The "IDE" is sh/bash/... How did you make your Qemu binary?

---
MS-DOS forever!

> > Who needs an IDE?
>
> I don't know. Didn't you notice the quotes? The "IDE" is sh/bash/... How
> did you make your Qemu binary?

Bash is "just" a general shell.
Would you call `command.com´ being an IDE too?

A nice (but blown) open source IDE (not for DOS) is Code::Blocks.

---
Forum admin

> Thanks! But then, I have no problem with FASM because I don't use it (IMO
> only MASM and NASM are generally usable tools in professional quality).

ACK. MASM is closed source but of very good quality. NASM is of fair quality, but it's multi platform and open source. FASM is small and fast, but closed source. If Tomasz ever decides to stop his project, it's gone.

---
Forum admin

> FASM is small and fast, but closed source. If Tomasz ever decides to stop his
> project, it's gone.

Is FASM closed source? I haven't read the license, but I remember that Randall Hyde recently announced to have included a modified version of FASM into HLA. IIRC HLA is Public Domain, and I'm also pretty sure that he didn't pay Tomazs to get a FASM source code license.

---
MS-DOS forever!

> > Thanks! But then, I have no problem with FASM because I don't use it
> (IMO
> > only MASM and NASM are generally usable tools in professional quality).
>

I'm not sure what you'd call professional quality. Maybe you mean "supporting all Win32 paradigms easily". That's probably one advantage to MASM. But NASM and FASM are plenty good if you don't rely too much on structs, macros, and other stuff. (You are of course free to use such, but remember that assembly itself does not include it. Only certain assemblers decide to support that. They are going "beyond the call of duty", so I don't consider FASM less for it. FASM and NASM (w/ NASMX) are both fully able to write Win32 programs.

> ACK. MASM is closed source but of very good quality. NASM is of fair
> quality, but it's multi platform and open source. FASM is small and fast,
> but closed source. If Tomasz ever decides to stop his project, it's gone.

They all have bugs. But people do use them all. So I guess they're all somewhat working. (Depends on needs and skill, I guess.)

And yes, FASM is open source (BSD-ish license, I think). Its all included in any FASM download. I mean, FASM can run on 9 OSes, at least (e.g. OctaOS), which also has the complete source. If it wasn't open source, would I be able to post this?

> Is FASM closed source?

It isn't. Sorry, my mistake!

---
Forum admin

> FASM and NASM (w/
> NASMX) are both
> fully able to write Win32 programs.

I already wrote small Win32s programs (for Windows 3.x) with old NASM 0.97 for DOS. That's almost 10 years ago!

> And yes, FASM is open source (BSD-ish license, I think).

Sorry, my mistake!

---
Forum admin

> > FASM and NASM
> (w/
> > NASMX) are both
> > fully able to write Win32 programs.
>
> I already wrote small Win32s programs (for Windows 3.x) with old NASM 0.97
> for DOS. That's almost 10 years ago!

The default NASM 0.97 for DOS runs out of memory quickly. But, RDF 1.1 is (AFAIK) the only "working" version of RDOFF that WDOSX supports, so in that case, I use NASM 0.97 (Win32 version, stubbed by WDOSX, heh, able to use more memory than 16-bit compile).

> > And yes, FASM is open source (BSD-ish license, I think).
>
> Sorry, my mistake!

Don't worry, we all make mistakes. (I misspelled "February" in two of my recent posts. Oops.)

But FYI, FASM is indeed a backend to various compilers: HLA, PureBasic, BlitzMax, Context/Win32, B0. (Taken from FASM's Wikipedia page.) So yes, it is freely available for most uses.

EDIT:

(LICENSE.TXT from latest version)

> flat assembler version 1.67
> Copyright (c) 1999-2007, 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).

> > 5. Seems that POASM supports only COFF
> Agreed. I'm not in the mood to defend this thing.

You just suggested it before :-\

> But yes, I also sometimes see people complaining about MASM's "bracket
> rules". Usually these are ASM noobees (a rather annoying species IMO)

Like Tomasz

> don't know the difference between a variable and the address of a variable.

> IMO only MASM and NASM are generally usable tools in professional quality

Argument doesn't work: NASM also has the critical design fault of neglecting "the difference between a variable and the address of a variable" - even worse, it was the first one and introduced this "bug"

> > ... thus GCC/AS/LD do work also , just the "IDE" doesn't ?
> Yes, but without the "IDE" it's impossible to MAKE a project.

Thanks ... thus the only Win32 C compiler working well on HX is TCC

Anyway, this thread is evolving badly, the time has come to summarize:

- All assemblers except MASM and TASM do suck
- FASM is buggy, open source, free, self-compiling, doesn't need "offset"/"ptr"/"assume" stuff, has a native DOS version with IDE, a support forum, supports many output formats useful in DOS (raw binary, MZ, PE, COFF (?)), and sucks most
- POASM is buggy, doesn't work in DOS, is somewhat similar to MASM, but "POASM iss not MASM. Again, RTFM." ...
- WASM is buggy and still a toy ...
- There are many assemblers similar to MASM, but none of them can compile HX, either they are old (Arrow - MASM 3.xx), or have very little interest in 100% compatibility (PO, WASM) ... btw, is MASM 6.xx compatible with MASM 5.xx at all ?
- YASM has 100% MASM compatibility on the wishlist, but this doesn't mean anything ...
- The exclusivity for MASM to compile MASM code is guaranteed for the next 10'000'000'000 years

A won't answer to this thread anymore, the time has come to stop this

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

> > IMO only MASM and NASM are generally usable tools in professional
> quality
>
> Argument doesn't work: NASM also has the critical design fault of
> neglecting "the difference between a variable and the address of a
> variable" - even worse, it was the first one and introduced this "bug"
>

Sorry, you missed the point. The "bracket/offset issue" is not a crucial thing. What is crucial to be "professional" is support for OMF + COFF and no severe bugs.

> btw, is MASM 6.xx compatible with MASM 5.xx at all ?
> ...
> A won't answer to this thread anymore, the time has come to stop this

Rather impolite - and also looks slightly foolish - to ask a question and then telling that you won't respond anymore. Btw, who is A?

---
MS-DOS forever!

> A won't answer to this thread anymore

A who?

> the time has come to stop this

Do you know that you have the right to skip over subjects that bore you? Neverheless, I will obey.