DOS ain't dead

JWasm v1.8 is almost mature.

major changes:

- Masm v5.1 compatibility option -Zm
- support for listings
- COFF output format
- lots of bugfixes

http://www.japheth.de/JWasm.html

With COFF support implemented in JWasm, I was able to switch the assembler used for HX. Now virtually all modules are assembled with JWasm. Masm must die!

http://www.japheth.de/Download/hxrtd.zip

---
MS-DOS forever!

Japheth wrote:

> JWasm v1.8 is almost mature.
> - Masm v5.1 compatibility option -Zm

WOW ! Can it compile RX-DOS ?

> - support for listings
> - COFF output format

Wow ... but any benefit except that it allows using PO-link ?

> - lots of bugfixes

1'000'000 bugs fixed ... as usual

> With COFF support implemented in JWasm, I was able to switch the assembler
> used for HX. Now virtually all modules are assembled with JWasm.

COOL. WLINK bug (500 DKRNL exports are too much ??? ) affects OMF only ?

> Masm must die!

Wow

> I will defend MASM

wow

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

wow

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

> Japheth wrote:
>
> > JWasm v1.8 is almost mature.
> > - Masm v5.1 compatibility option -Zm
>
> WOW ! Can it compile RX-DOS ?

I don't know. Is this of any relevance? It can compile the "lost" UIDE.ASM.

> > - support for listings
> > - COFF output format
>
> Wow ... but any benefit except that it allows using PO-link ?

Yes. It allows to use GNU ld - if the COFF "emulation" is supported, as it is in DGPJJ's ld. Also, there are some restrictions in OMF which are not present in COFF (OTOH, some things can only be done with OMF). Finally, there are lots of PE tools which will accept the JWasm COFF output, while OMF tools are now somewhat "obsolete".

> > With COFF support implemented in JWasm, I was able to switch the
> assembler
> > used for HX. Now virtually all modules are assembled with JWasm.
>
> COOL. WLINK bug (500 DKRNL exports are too much ??? ) affects
> OMF only ?

No. I don't use WLINK for the Win32 emulation binaries.

> > Masm must die!
>
> Wow
>
> > I will defend MASM
>
> wow

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

"the better is the enemy of the good"

---
MS-DOS forever!

> > Japheth wrote:
> >
> > > JWasm v1.8 is almost mature.
> > > - Masm v5.1 compatibility option -Zm
> >
> > WOW ! Can it compile RX-DOS ?

I'm working on a NASM port of RxDOS. (Actually it's neither RX-DOS nor RXDOS...)

First I started compiling the last MASM source from the FreeDOS mirrors with a copy of MASM 5.1, LINK 5.6, NMAKE 1.50 (Win32 only) and EXE2BIN 1.5 from OpenWatcom (also included in FreeDOS). This worked well after some small makefile adjustments.

I don't do it that way anymore but now tryed the same with JWasm 1.8pre -Zm. I had to edit the makefile often because JWasm doesn't understand Masm's terrible syntax. (input_file,obj_dir; changed to -Foobj_file input_file for each file.) But then JWasm started throwing numerous E032 errors (syntax error). Looks like it doesn't understand addresses like word ptr [label. offset] which you'll write as word [label + offset] in NASM syntax. There might be other problems though because I didn't checked/edited the errors.

> I don't know. Is this of any relevance?

For RxDOS: If I'll ever finish my port, NO

For JWasm: Yes, because the old RxDOS doesn't use any bugs of Masm (or I just didn't see it yet because there were too many other errors from JWasm) but still doesn't compile with JWasm.

> It can compile the "lost" UIDE.ASM.

OTOH porting the "drivers" should be possible without much work if one ever needs it. I don't use them anyway.

---
l

> I'm working on a NASM port of RxDOS. (Actually it's neither RX-DOS nor
> RXDOS...)

Interesting. Can a modified RxDOS be distributed - at least for non-commercial use?

> > I don't know. Is this of any relevance?
>
> For RxDOS: If I'll ever finish my port, NO
>
> For JWasm: Yes, because the old RxDOS doesn't use any bugs of Masm (or I
> just didn't see it yet because there were too many other errors from
> JWasm) but still doesn't compile with JWasm.

I just tried to assemble some RxDOS modules with Masm v6 and -Zm switch. It didn't work. If Masm v6 cannot assemble it, then there's no need for JWasm to be able to do so.

---
MS-DOS forever!

> > I'm working on a NASM port of RxDOS. (Actually it's neither RX-DOS nor
> > RXDOS...)
>
> Interesting. Can a modified RxDOS be distributed - at least for
> non-commercial use?

RxDOS response from Mike Podanoffsky

"I welcome both further testing and ports to open source Assemblers like NASM."

> > For JWasm: Yes, because the old RxDOS doesn't use any bugs of Masm (or
> I
> > just didn't see it yet because there were too many other errors from
> > JWasm) but still doesn't compile with JWasm.
>
> I just tried to assemble some RxDOS modules with Masm v6 and -Zm switch.
> It didn't work. If Masm v6 cannot assemble it, then there's no need for
> JWasm to be able to do so.

Don't forget that RxDOS was ported to A86 also. See here.

> Interesting. Can a modified RxDOS be distributed - at least for
> non-commercial use?

The RxDOS distributed on the FreeDOS mirror is licensed under the GNU GPL. (This and the fact that it's done in Assembly only led me to choose it over FreeDOS and (E)DR-DOS.)

> I just tried to assemble some RxDOS modules with Masm v6 and -Zm switch.
> It didn't work. If Masm v6 cannot assemble it, then there's no need for
> JWasm to be able to do so.

Sorry, I didn't know that JWasm just mimics Masm's option here. So it's ok the old RxDOS won't compile with JWasm.

Just for curious, did it throw the same errors I reported? (I tryed compiling RXDOS.ASM, first source file of RXDOS.SYS.)

---
l

> > Interesting. Can a modified RxDOS be distributed - at least for
> > non-commercial use?
>
> The RxDOS distributed on the FreeDOS mirror is licensed under the GNU GPL.
> (This and the fact that it's done in Assembly only led me to choose it over
> FreeDOS and (E)DR-DOS.)
>
> > I just tried to assemble some RxDOS modules with Masm v6 and -Zm
> switch.
> > It didn't work. If Masm v6 cannot assemble it, then there's no need for
> > JWasm to be able to do so.
>
> Sorry, I didn't know that JWasm just mimics Masm's option here. So it's ok
> the old RxDOS won't compile with JWasm.
>
> Just for curious, did it throw the same errors I reported? (I tryed
> compiling RXDOS.ASM, first source file of RXDOS.SYS.)

No. I happened to choose modules RXDOSMEM.ASM and RTDOSPRM.ASM. With the first JWasm had no problems, with the second there were 3 errors, as far as I understand it's because there's a macro "Goto", which has become a reserved word in Masm v6. Masm v6 also seems to have problems with "Goto", but displays totally different error messages.

---
MS-DOS forever!

> > Can it compile RX-DOS ?
> I don't know. Is this of any relevance?

YES.

1. DOS kernel
2. In ASM
3. GNU GPL (more free than "evil" EDR-DOS)
4. LFN support in the kernel (?) - less bad than DOSLFN ?

> No. I don't use WLINK for the Win32 emulation binaries.

What do you use then PO ? LD ? Still M ? Thus the "unreasonably-many-exports-bug" is independent of source format and makes it unusable for the DLL's ? Any idea / suspect what is the reason of the bug ? An overflow is trivial to fix - after having found it

> macro "Goto", which has become a reserved word in Masm v6
> Masm v5.1 compatibility option -Zm

Thus this option is experimental / incomplete for now ?

cm wrote:

> I'm working on a NASM port of RxDOS.

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

> > > Can it compile RX-DOS ?
> > I don't know. Is this of any relevance?
>
> YES.
>
> 1. DOS kernel
> 2. In ASM
> 3. GNU GPL (more free than "evil" EDR-DOS)
> 4. LFN support in the kernel (?) - less bad than DOSLFN ?

The source is "almost" compatible. The main problem is that the "." operator is used as an alias for "+". This can be cured by replacing the following strings in all ASM files:

  ". _low"     -> "+ _low"
  ". _high"    -> "+ _high"
  ". _pointer" -> "+ _pointer"
  ". _segment" -> "+ _segment"
  ". _AL"      -> "+ _AL"
  ". _DL"      -> "+ _DL"

this eliminates about 98% of the errors. Another 1.5% is eliminated by changing GoTo to @GoTo (GOTO has become a reserved word in Masm v6).

The small rest are trivial things (sometimes the space is missing between "." and _low/_high, once a STRUCT is defined "too late" and must be moved) which are easy to fix.

A brief test of the newly generated rxdoscmd.exe was successful.


> What do you use then PO ? LD ? Still M ? Thus the
> "unreasonably-many-exports-bug" is independent of source format and makes
> it unusable for the DLL's ? Any idea / suspect what is the reason of the
> bug ? An overflow is trivial to fix - after having found it

It's not a bug. The problem with WLink is that it wants the decorated name for exports. And I'm not in the mood to calculate the @size prefix for about 1.000 functions and add it to the wlink response file (although, I vaguely remember a tool LIB2DEF which creates .DEF files from import libs and might be used for this task). Currently PoLink/MS link is still used.

> Thus this option is experimental / incomplete for now ?

It's incomplete, and it's documented that it's incomplete. RTFM!

---
MS-DOS forever!

> Don't forget that RxDOS was ported to A86 also. See
> here.

And both MASM and A86 support .LST generation, so that should make porting to NASM much much easier, no? (Raw machine code might be easier to understand than some high-level asm constructs.)

> The source is "almost" compatible. The main problem is that the "."
> operator is used as an alias for "+". This can be cured by replacing the
> following strings in all ASM files:
>
>   ". _low"     -> "+ _low"
> ". _high"    -> "+ _high"
> ". _pointer" -> "+ _pointer"
> ". _segment" -> "+ _segment"
> ". _AL"      -> "+ _AL"
> ". _DL"      -> "+ _DL"
>
> this eliminates about 98% of the errors. Another 1.5% is eliminated by
> changing GoTo to @GoTo (GOTO has become a reserved word in Masm v6).
>
> The small rest are trivial things (sometimes the space is missing between
> "." and _low/_high, once a STRUCT is defined "too late" and must be moved)
> which are easy to fix.
>
> A brief test of the newly generated rxdoscmd.exe was successful.

I uploaded the modified files:

http://www.japheth.de/Download/rxdos_src.zip

JWasm v1.8 and OW WLink are used. I'm not sure if OW "WMake -ms" is ok, but NMAKE can create the binaries.

---
MS-DOS forever!

> The source is "almost" compatible. The main problem is that the "."
> Another 1.5% is eliminated by changing GoTo to @GoTo
> The small rest are trivial things (sometimes the space is missing between
> A brief test of the newly generated rxdoscmd.exe was successful.



> It's not a bug. The problem with WLink is that it wants
> Currently PoLink/MS link is still used.

What's evil with VALX ?

> RTFM

I will

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

> And both MASM and A86 support .LST generation, so that should make porting
> to NASM much much easier, no? (Raw machine code might be easier to
> understand than some high-level asm constructs.)

AFAIK, RxDOS doesn't use any high-level MASM directives. It has some simple macros but I already translated them to NASM macros. (Though I didn't test them all yet.)

---
l

> JWasm v1.8 is almost mature.
>
> major changes:
>

Sorry for bumping this thread (with no newer threads mentioning 1.9, go figure), but I found this TASM info interesting (from an old comp.lang.asm.x86 topic on Google Groups):

P.S. Wasn't the final version of TASM 5.3?

>> Kurt Johmann <johm...@atlantic.net> wrote:
>> Thanks for the replies. From your responses I get the
>> impression that maybe the info at the Borland site doesn't
>> mention optimizations for TASM because it doesn't have any.
>
> TASM disappeared from Borland's web site last year and didn't
> reappear until recently (under ..borlandcpp/cppcomp/tasmfact,
> the cpp means C++ companion product, I guess). Unlike Microsoft
> who seem to have gone completely silent about MASM, Borland
> keeps TASM alive (not kicking, but alive). After a 30% cut in
> the work force at Borland, TASM's future doesn't look bright.
>
> TASM does have a number of 'extensions' some of which can be
> disabled (using directives, not a switch) while others can't.
> As a file attachment (it's big, I know, but getting this
> information from Borland is like pulling teeth), you'll find
> a list of these covering TASM version 4.0.
>
> Version 5.0 (the 32-bit TASM32.EXE, only) adds support for
> several MASM 6.x features (but not MMX or PPro instructions):
> - BYTE, WORD, DWORD, FWORD, QWORD, TBYTE data definition
> directives
> - Signed integer types: SBYTE, SWORD, SDWORD
> - Floating-point types: REAL4, REAL8, REAL10
> - New decision and looping directives and run-time operators:
> .IF, .ELSE, .ELSEIF, .ENDIF
> .WHILE, .ENDW, .BREAK, .CONTINUE
> .REPEAT, .UNTIL, .UNTILCXZ
> ==, !=, >=, <=, <, >, &&, ||, !
> ZERO?, CARRY?, OVERFLOW?, SIGN?, PARITY?
> Example:
> assume eax:sdword,edx:sdword
> mov eax, ebx
> .while eax != ecx
> .break .if eax == edx
> .continue .if eax > edx
> inc eax
> .endw
> ;...
> .while carry?
> ;...
> .endw
> - STRUCT, EXTERN, PROTO
> - PRIVATE, PUBLIC, and EXPORT visibility in PROCs
> - NEAR16, NEAR32, FAR16, FAR32 distance in PROCs (386+)
> - Several aspects of OPTION: casemap, dotname/nodotname,
> emulator/noemulator, expr16/expr32, ljmp/noljmp, nokeyword,
> proc, scoped/noscoped, segment (others are recognized, but
> ignored)
> - Miscellaneous: TEXTEQU, REPEAT, FOR, FORC, ECHO, EXTERNDEF
>
> INVOKE and ADDR aren't supported by TASM apparently because
> there is a number of problems with these that Borland doesn't
> want to replicate for the sake of compatibility.
>
> May 18th, 1997
> Morten Elling

> Sorry for bumping this thread (with no newer threads mentioning 1.9, go
> figure)

Since Jul 24, jwasm v1.9 is available:

http://www.japheth.de/JWasm.html

there's also an - unstable - v1.91, which supports output of plain binaries. So no linker is needed to create DOS .COM and .SYS files.

---
MS-DOS forever!

Hello,

today Steve Hutchesson has added a Subforum for JWasm to his Masm32 board. The caption is "Open Watcom Assembler". Bug reports should be posted there.

http://www.masm32.com/board/

---
MS-DOS forever!

> Hello,
>
> today Steve Hutchesson has added a Subforum for JWasm to his Masm32 board.
> The caption is "Open Watcom Assembler". Bug reports should be posted
> there.

Strange caption for something that's only a fork (last I heard). But a good fork it is! Heck, OW's latest WASM/WASMR snapshots (DOS only) seem completely broken!!

a new release.

major changes:

- /bin cmdline option allows to create binaries without linker
- bugfixes

2 of the bugs fixed are critical as far as segmented memory models are concerned, therefore the upgrade to this release is highly recommended.

http://www.japheth.de/JWasm.html

changelog:
http://www.japheth.de/JWasm/history.txt

---
MS-DOS forever!

> a new release.



> major changes:
> - /bin cmdline option allows to create binaries without linker

Most sophisticated format as last

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

> > a new release.
>
>
>
> > major changes:
> > - /bin cmdline option allows to create binaries without linker
>
> Most sophisticated format as last

it's good for small tools and noobies who wonder what this "linker"-thingy might be good for.

---
MS-DOS forever!

> P.S. Wasn't the final version of TASM 5.3?

Apparently, yes (from 2000), dual 32RTM/DOS and Win32 .EXE (188k). It must be abandoned (more or less) since the free Turbo C++ Explorer (2006, Win32 only) has it (in DATA1.CAB, and that's a pretty huge download (390 MB), plus prerequisites (228 MB), so definitely not recommended, esp. since TASM lacks some modern instruction sets ... heck, I couldn't even figure out how to install it, stupid prerequisites!!). But hey, old code uses a lot of TASM "quirks", so maybe somebody has a use for it. Otherwise, migrating to JWasm (or "wimpier" assemblers like FASM or NASM) would be better.

P.S. The 32-bit FASM runs fine under x86-64 XUbunutu. Most other simple 32-bit stuff doesn't (no 32-bit dynamic libs installed??), which is lame IMO. Even their GCC/G++ doesn't handle -m32 by default (which I think it should). But anyways, enough of a tangent .... Hmmm, maybe I should try JWasm under x86-64 XUbuntu, but I suspect only a "-static" compile will run there.

> heck, I couldn't even figure out how to install it, stupid prerequisites!!).

What do you mean? I succeeded to unpack tasm32.exe from using Total Commander. Seems to work with 7-Zip (Win32) too.

---
Forum admin

> > heck, I couldn't even figure out how to install it, stupid
> prerequisites!!).
>
> What do you mean? I succeeded to unpack tasm32.exe from using Total
> Commander. Seems to work with 7-Zip (Win32) too.

The compiler itself wouldn't install if no prerequisites were present, so you had to install them separately (but it was a .ZIP, and I wasn't sure where to unzip to, let it automatically install them or otherwise, or if even really needed since Vista already has .NET runtimes). So, I didn't have much luck and didn't look too further.

There are so many other compilers around. OW is very easy to install.

---
Forum admin

http://www.japheth.de/JWasm.html

http://www.japheth.de/JWasm/history.txt

---
MS-DOS forever!

> JWasm v1.92 is out



1'000'000 bugs fixed, debug enhancements not yet done. Any chance for a HX update now or does it badly need the full debug support ?

BTW, IIRC I compiled the PESTUB finally (long ago, JW 1.90 or so) ... but no idea how to link

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

> Any chance for a HX update now or does it badly need the full debug support ?

Yes.

> BTW, IIRC I compiled the PESTUB finally (long ago, JW 1.90 or so) ... but
> no idea how to link

Perhaps you can convert it to Fasm, thus you don't need to link it ...

---
MS-DOS forever!

> > BTW, IIRC I compiled the PESTUB finally (long ago, JW 1.90 or so) ... but
> > no idea how to link
>
> Perhaps you can convert it to Fasm, thus you don't need to link it ...

NO! You need to create JFasm! And make sure it's free of BUG's!

> Yes.

To update soon or waiting for debug support ?

> Perhaps you can convert it to Fasm, thus you don't need to link

Sure I can but most likely not worth the pain.

BTW, new test with 1.92:

Old bug fixed (failure to provide -DFLAT raised 1'000'000 errors), but
new bug: Name in WINNT.INC is evil, NName helped ... up to OBJ only

Steve wrote:

...

Done ! Check your inbox

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

> Old bug fixed (failure to provide -DFLAT raised 1'000'000 errors),
> but
> new bug: Name in WINNT.INC is evil, NName helped ...
> up to OBJ only

Actually it is/was a bug in winnt.inc. NAME is a Masm directive and misusing it as a field name won't have the desired effects - because the line is virtually ignored ... by both Masm and old versions of JWasm.

---
MS-DOS forever!

> Actually it is/was a bug in winnt.inc. NAME is a Masm directive and misusing

I see

But I found 2 (or is it just 1 ?) (or ZERO - feature ???) bugs:

UD2 and INT3 instructions don't work.

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

> > Actually it is/was a bug in winnt.inc. NAME is a Masm directive and
> misusing
>
> I see
>
> But I found 2 (or is it just 1 ?) (or ZERO - feature ???) bugs:
>
> UD2 and INT3 instructions don't work.

AFAIK Masm doesn't support these opcodes (SALC probably is another one). So there's no need to support them in JWasm.

---
MS-DOS forever!

> > UD2 and INT3 instructions don't work.
>
> AFAIK Masm doesn't support these opcodes (SALC probably is another one).
> So there's no need to support them in JWasm.

BTW, I've seen real-world apps use SALC (e.g. something by Tomasz of FASM), also known as SETALC. But yeah, it's rare. There's some trick to emulate it, something like SBB AL,AL. (EDIT: corrected, I hope!)

INT3 isn't supported in JWasm, but INT 3 works fine (and produces 0xCC, not 0xCD 0x03 in case you were wondering). Guess even Japheth doesn't know everything.

> AFAIK Masm doesn't support these opcodes (SALC probably is another one).
> So there's no need to support them in JWasm.

Considering MASM doesn't support SSSE3 either ... not to talk about CPUID and CR4 ... the argument seems not to work

Of course I can use DB to brew missing instructions

Tomasz wrote:

> especially hated the necessity of manually building some instruction opcodes with DB directive.

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

http://www.japheth.de/JWasm.html

http://www.japheth.de/JWasm/history.txt

---
MS-DOS forever!

Japheth wrote:

> JWasm v1.93 is out

It just has no date ...

Japheth wrote (4 months ago):

> JWasm v1.8 is almost mature.

It obviously wasn't But 1.93 is ?

3 interesting questions:

- Will JWASM replace WASM in OW 1.8 ? BTW, any idea when 1.8 is expected to come out, and whether it will include support of LOADPEX as well, or use it maybe ? 1.7a still heavily prefers DOG/4SW

- JWASM has a critical "fault". Not for DOS, but for the mainstream (see "other" forum). How long will Japheth be able to resist here ?

- Any chance for HX 2.15 switched to JWASM ? Well, linking and nmakeuping are not solved, however

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

> - Will JWASM replace WASM in OW 1.8 ? BTW, any idea when 1.8 is expected
> to come out, and whether it will include support of LOADPEX as well, or
> use it maybe ?

No.

> - JWASM has a critical "fault". Not for DOS, but for the mainstream
> (see "other" forum). How long will Japheth be able to resist here ?

What?

> - Any chance for HX 2.15 switched to JWASM ? Well, linking and nmakeuping
> are not solved, however

What?

---
MS-DOS forever!

> > - JWASM has a critical "fault". Not for DOS, but for the
> mainstream
> > (see "other" forum). How long will Japheth be able to resist here
> ?
>
> What?

Will Japheth finally be able to beat the quest to fix the ominous BUG''S reported by DOS386?

---
l

> No.
> What?
> What?

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

> > No.
> > What?
> > What?

> your answers made me dangerously smart

You probably know already: there don't exist stupid answers, just stupid questions.

---
MS-DOS forever!

> > > No.
> > > What?
> > > What?
>
> > your answers made me dangerously smart
>
> You probably know already: there don't exist stupid answers, just stupid
> questions.

Okay, since this is getting silly, let me report a minor bug:

rep cmpsb

doesn't work in latest JWasm (or Wasm, for that matter). The workaround is to just use "repz cmpsb" instead.

> Okay, since this is getting silly, let me report a minor bug:
>
> rep cmpsb
>
> doesn't work in latest JWasm (or Wasm, for that matter). The workaround is
> to just use "repz cmpsb" instead.

IIRC the <rep> prefix for cmpsb is intentionally rejected by Masm v6. If it's desperately wanted, one can enable Masm v5.1 compatibility with the -Zm switch, then the syntax is - or at least should be - accepted.

---
MS-DOS forever!

changelog: http://www.japheth.de/JWasm/history.txt

http://www.japheth.de/JWasm.html

---
MS-DOS forever!

some regressions made v1.94a and then v1.94b necessary.

---
MS-DOS forever!

> some regressions made v1.94a and then v1.94b necessary.

Still says 1.94a, so either you silently refreshed or haven't finished yet. Or maybe forgot to re-upload it??

Anyways, thanks for your work!

> > some regressions made v1.94a and then v1.94b necessary.
>
> Still says 1.94a, so either you silently refreshed or haven't finished
> yet. Or maybe forgot to re-upload it??

Now it's 1.94c.

---
MS-DOS forever!

Japheth wrote:

> > > JWasm v1.94
> > some regressions made v1.94a and then v1.94b necessary.
> Now it's 1.94c.

COOL. And now it's 1.95pre, only 14 more BUG's fixed

> You probably know already: there don't exist stupid answers, just stupid questions.

I've seem them

> > > > What?
> > > > What?

Jimg wrote:

> If only it were written in jwasm rather than C I'd jump all over it!

Regrettably self compilability is a feature unique to FASM

Maybe there are neither stupid answers, nor stupid questions, just stupid dreams ?

And maybe it would be a good idea to lock this > 1/2 year old, obsolete and messy 1.8pre (!!!) thread and open a new one, at occasion of 1.95 final ?

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

> Jimg
> wrote:
>
> > If only it were written in jwasm rather than C I'd jump all over it!
>
> Regrettably self compilability is a feature unique to FASM

It's a known defect of the human brain: reason is just a slave, people believe what they want to believe.

---
MS-DOS forever!

> > Jimg
> > wrote:
> >
> > > If only it were written in jwasm rather than C I'd jump all over it!

In other words, if Jimg knew C as well as assembly, he'd try forking / maintaining it?? I doubt that. But anyways, at least it's more robust than OpenWatcom's WASM (although I swear I thought someone wanted to bring it into the fold and keep both, which sounded sensible to me, but that hasn't happened for 1.8 RC1 at least).

> > Regrettably self compilability is a feature unique to FASM
>
> It's a known defect of the human brain: reason is just a slave, people
> believe what they want to believe.

FASM ain't the only assembler to assemble itself: Octasm, Wolfware, TMA, NBASM16, NGASM, A86, Intasm, XASM, Rosasm, etc. But most of those don't support multiple output formats well, if at all. And most of those aren't portable, so FASM is definitely superior, IMHO.

> portable, so FASM is definitely superior, IMHO.

Since we are in a DOS forum here: for DOS programming , especially 16bit, FASM is inferior IMVHO, simply because there's no support for OMF output format implemented.

> FASM ain't the only assembler to assemble itself: ...

The fact that it is written in ASM and can be assembled by itself is probably worth to be mentioned, but not as an advantage but as a disadvantage.

And what do you mean by "robust"?

---
MS-DOS forever!