Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Japheth

Homepage

Germany (South),
17.06.2008, 11:04
 

JWasm v1.8pre (Announce)

Post reply

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

18.06.2008, 12:23

@ Japheth
 

JWasm v1.8pre | killing MA$M now ???

Post reply

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 :clap:

> 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 :confused: ??? ) affects OMF only ?

> Masm must die!
Wow :clap:

> 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

Homepage

Germany (South),
18.06.2008, 14:34

@ DOS386
 

JWasm v1.8pre | killing good MASM now ???

Post reply

> 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 :confused: ??? ) affects
> OMF only ?
No. I don't use WLINK for the Win32 emulation binaries.

> > Masm must die!
>
> Wow :clap:
>
> > 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!
ecm

Homepage E-mail

Düsseldorf, Germany,
18.06.2008, 16:58

@ Japheth
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

> > 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 :clap:

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
Japheth

Homepage

Germany (South),
18.06.2008, 19:17

@ ecm
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

> 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 :clap:
>
> 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!
Rugxulo

Homepage

Usono,
18.06.2008, 19:38

@ Japheth
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

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

Homepage

Usono,
19.06.2008, 23:43

@ Rugxulo
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

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

Homepage E-mail

Düsseldorf, Germany,
20.06.2008, 12:58

@ Rugxulo
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

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

Homepage E-mail

Düsseldorf, Germany,
18.06.2008, 19:46

@ Japheth
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

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

Homepage

Germany (South),
18.06.2008, 19:55

@ ecm
 

JWasm v1.8pre | killing good MASM now ??? | Compiling RxDOS

Post reply

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

19.06.2008, 08:33

@ Japheth
 

JWasm v1.8pre | killing good MASM now ???

Post reply

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

Homepage

Germany (South),
19.06.2008, 10:02

@ DOS386
 

JWasm v1.8pre | killing good MASM now ???

Post reply

> > > 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! :-D

---
MS-DOS forever!
Japheth

Homepage

Germany (South),
20.06.2008, 07:47

@ Japheth
 

rxdos + jwasm

Post reply

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

20.06.2008, 09:33

@ Japheth
 

JWasm v1.8pre | WLINK | PO | M | VALX

Post reply

> 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 :hungry:

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

Homepage

Usono,
07.08.2008, 07:09

@ Japheth
 

JWasm v1.8pre

Post reply

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

Homepage

Germany (South),
07.08.2008, 10:04

@ Rugxulo
 

JWasm v1.9 available

Post reply

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

Homepage

Usono,
20.08.2008, 22:29

@ Rugxulo
 

JWasm v1.8pre

Post reply

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

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

Homepage E-mail

Berlin, Germany,
21.08.2008, 14:37

@ Rugxulo
 

JWasm v1.8pre

Post reply

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

Homepage

Usono,
21.08.2008, 22:04

@ rr
 

JWasm v1.8pre

Post reply

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

Homepage E-mail

Berlin, Germany,
21.08.2008, 22:36

@ Rugxulo
 

JWasm v1.8pre

Post reply

There are so many other compilers around. ;-) OW is very easy to install. :-D

---
Forum admin
Japheth

Homepage

Germany (South),
14.08.2008, 16:41

@ Japheth
 

JWasm Forum

Post reply

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

Homepage

Usono,
17.08.2008, 00:25

@ Japheth
 

JWasm Forum

Post reply

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

Homepage

Germany (South),
20.08.2008, 07:02

@ Japheth
 

JWasm v1.91

Post reply

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

20.08.2008, 07:52

@ Japheth
 

JWasm v1.91

Post reply

> a new release.
:-)

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

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

Homepage

Germany (South),
20.08.2008, 10:33

@ DOS386
 

JWasm v1.91

Post reply

> > a new release.
>
> :-)
>
> > major changes:
> > - /bin cmdline option allows to create binaries without linker
>
> Most sophisticated format as last :lol3:
it's good for small tools and noobies who wonder what this "linker"-thingy might be good for.

---
MS-DOS forever!
Japheth

Homepage

Germany (South),
23.09.2008, 09:48

@ Japheth
 

JWasm v1.92 is out

Post reply

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

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

---
MS-DOS forever!
DOS386

23.09.2008, 16:06

@ Japheth
 

JWasm v1.92 is out

Post reply

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

Homepage

Germany (South),
24.09.2008, 14:03

@ DOS386
 

JWasm v1.92 is out

Post reply

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

Homepage E-mail

US,
24.09.2008, 23:44

@ Japheth
 

JWasm v1.92 is out

Post reply

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

25.09.2008, 15:55

@ Japheth
 

JWasm v1.92 is out | fixed old bug | added new bug

Post reply

> 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 :hungry:

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

Homepage

Germany (South),
25.09.2008, 17:21

@ DOS386
 

JWasm v1.92 is out | fixed old bug | added new bug

Post reply

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

04.10.2008, 04:39

@ Japheth
 

JWasm v1.92 is out | many bugs found

Post reply

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

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

Homepage

Germany (South),
04.10.2008, 08:53

@ DOS386
 

JWasm v1.92 is out | many bugs found

Post reply

> > Actually it is/was a bug in winnt.inc. NAME is a Masm directive and
> misusing
>
> I see :clap:
>
> 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!
Rugxulo

Homepage

Usono,
04.10.2008, 20:28
(edited by Rugxulo, 04.10.2008, 23:25)

@ Japheth
 

JWasm v1.92 is out | many bugs found

Post reply

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

05.10.2008, 13:47

@ Japheth
 

JWasm v1.92 is out | many bugs found

Post reply

> 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 :clap:

Of course I can use DB to brew missing instructions :hungry:

Tomasz wrote:

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

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

Homepage

Germany (South),
26.10.2008, 20:06

@ Japheth
 

JWasm v1.93 is out

Post reply

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

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

---
MS-DOS forever!
DOS386

29.10.2008, 09:46

@ Japheth
 

JWasm v1.93 is out

Post reply

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 :clap: 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 ***
Japheth

Homepage

Germany (South),
29.10.2008, 13:59

@ DOS386
 

JWasm v1.93 is out

Post reply

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

Homepage E-mail

Düsseldorf, Germany,
29.10.2008, 19:59

@ Japheth
 

JWasm v1.93 is out

Post reply

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

11.11.2008, 15:02

@ Japheth
 

WARNING: your answers made me dangerously smart :-D

Post reply

> No.
> What?
> What?

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

Homepage

Germany (South),
07.12.2008, 15:04

@ DOS386
 

WARNING: your answers made me dangerously smart :-D

Post reply

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

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
07.12.2008, 20:28

@ Japheth
 

minor bug: REP CMPSB

Post reply

> > > No.
> > > What?
> > > What?
>
> > your answers made me dangerously smart :-D
>
> You probably know already: there don't exist stupid answers, just stupid
> questions. :crying:
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.
Japheth

Homepage

Germany (South),
07.12.2008, 22:37

@ Rugxulo
 

minor bug: REP CMPSB

Post reply

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

Homepage

Germany (South),
19.12.2008, 18:19

@ Japheth
 

JWasm v1.94

Post reply

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

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

---
MS-DOS forever!
Japheth

Homepage

Germany (South),
21.12.2008, 15:05

@ Japheth
 

JWasm v1.94a and b

Post reply

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

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
23.12.2008, 07:13

@ Japheth
 

JWasm v1.94a and b

Post reply

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

Homepage

Germany (South),
24.12.2008, 12:50

@ Rugxulo
 

JWasm v1.94a, b and c

Post reply

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

29.12.2008, 01:27

@ Japheth
 

JWasm v1.94a, b and c and 1.95 pre

Post reply

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 :-P

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

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

Homepage

Germany (South),
29.12.2008, 08:31

@ DOS386
 

Reason isn't easy to find ...

Post reply

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

Homepage

Usono,
29.12.2008, 23:28

@ Japheth
 

JWasm and FASM are more robust than others

Post reply

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

Homepage

Germany (South),
30.12.2008, 08:10

@ Rugxulo
 

FASM is inferior for DOS programming

Post reply

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

Homepage

Usono,
30.12.2008, 20:14

@ Japheth
 

FASM can't understand OMF ".OBJ" files

Post reply

> > 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.
OMF is really only necessary for linking between HLLs and assembly, and only a few less-popular compilers support it (Digital Mars, Borland, OpenWatcom). If you don't need HLL-compiled objects, just write it all in FASM (like Tomasz does). Besides, were any of those compilers free in 1999? (Not OpenWatcom, 2003). So there would be no incentive for Tomasz (gratis) to support that which he doesn't use. Especially since all three of those compilers above supports some form of assembly (inline or external, at least).

OMF is complex, which Tomasz has lamented before. But yes, no OMF support in FASM does vaguely limit its usefulness. However, no one has volunteered to add it thus far, so they must not need it too bad ("why reinvent the wheel?" NASM, WASM, LZASM, MASM, TASM, A86/A386, Arrowsoft, SOLASM, etc. etc.). Windows and Linux don't use it, and that's 90% of the popular market right there.

FASM initially started as a DOS-only assembler with PE/COFF supported later on (1.04, apparently). Actually, it seems 1.10 only supports flat binary (.COM), MZ, and PE. So no object format support at all, initially. FASM didn't support COFF output until 1.39.

Also, as you know, some programmers prefer FLOSS or open source, hence they use whatever is available (e.g. GCC). And GCC is a GNU pet project, so any vestige of 16-bit or non-*nix-ness is heavily frowned upon. (And NASM is LGPL, which is "good enough" to license nerds.)

Besides, both FASM and OpenWatcom need a 386 to run, and there are other so-called "better" formats for that. A popular excuse is that the 386 has been around so long that it's ubiquitous. Same with FPU, everyone just assumes one is available now. Compatibility is a lost art.

Even COFF for DJGPP (which was originally a.out) is considered old hat, i.e. not as good as ELF. You could even argue that OMF is a DOS legacy format, and you know how (un)popular DOS is these days .... :-(

But Wikipedia does say NASM 0.90 (Oct. 1996) had 16-bit (only) support for .OBJ.

> > 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.
How is it a disadvantage? Harder to debug? It's not maintained by a group, only by Tomasz. And he's more comfortable with it than HLLs, obviously. If we were talking Haskell or Erlang, I'd agree. But x86 assembly isn't that rare. (Besides, you kinda have to know assembly to write an assembler. May as well test it on itself.) But I'll admit that writing it in assembly doesn't by default make it "better", nor is JWasm "worse" due to being in C (obviously).

> And what do you mean by robust?

Etymology:
   Latin robustus oaken, strong, from robor-, robur oak, strength
Date:
   1533

1 a: having or exhibiting strength or vigorous health b: having or showing vigor, strength, or firmness <a robust debate> <a robust faith> c: strongly formed or constructed : sturdy <a robust plastic> d: capable of performing without failure under a wide range of conditions <robust software>


I meant more powerful, error-free, useful, actively maintained. Why, are there any practical reasons for me to prefer Wasm instead of JWasm? Unless I wanted to run WASMR on an old 16-bit cpu (which I don't have), I see no advantage to it. I hesitate to also mention that UPX won't pack JWasm, sniff. BLOAT! ;-) j/k
Japheth

Homepage

Germany (South),
01.01.2009, 19:33

@ Rugxulo
 

FASM can't understand OMF ".OBJ" files

Post reply

> OMF is really only necessary for linking between HLLs and assembly
That's a very simplistic view of a linker. Linker can be useful/necessary if no HLLs are involved at all. They are even useful if there's just a single module to be linked to a binary.

> OMF is complex, which Tomasz has lamented before. But yes, no OMF support
> in FASM does vaguely limit its usefulness. However, no one has volunteered
> to add it thus far, so they must not need it too bad ("why reinvent the
> wheel?" NASM, WASM, LZASM, MASM, TASM, A86/A386, Arrowsoft, SOLASM, etc.
> etc.). Windows and Linux don't use it, and that's 90% of the popular
> market right there.
That's true, but the argument has little weight. An assembler which claims to support 16bit has to support OMF. OMF is complex because it's very old, created in a time when the need to reduce space did justify virtually everything. But hey, noone did claim that writing an assembler is pure fun. There are always tasks which are boring and dull. The difference between a hobby project and a tool of professional quality is that the "boring" things have been done as well in the latter case.

> How is it a disadvantage?
Asm is less portable. An assembler is among those kind of tools where the higher degree of portability of C is a REAL advantage.

A second disadvantage is that a self-compiling tools can worsen the effect of undetected bugs. If a buggy tool is used for compilation, pretty strange effects are likely to occur, sometimes very hard to fix.

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
02.01.2009, 04:45
(edited by Rugxulo, 02.01.2009, 04:56)

@ Japheth
 

FASM can't understand OMF ".OBJ" files

Post reply

> > OMF is really only necessary for linking between HLLs and assembly
>
> That's a very simplistic view of a linker. Linker can be useful/necessary
> if no HLLs are involved at all. They are even useful if there's just a
> single module to be linked to a binary.
Really? You're more experienced than me, so I defer to your knowledge. But in my experience, you don't NEED a linker if you're writing the entire project in FASM anyways. Tomasz doesn't need .OBJ, so he didn't implement .OBJ.

Compiling separate modules may be faster than all-at-once, but FASM is easily the fastest assembler I've tried (esp. on older computers). Then again, I haven't tried JWasm too too much on my old 486. (BTW, StarLFN apparently works fine with JWasm. Heh. Then again, StarLFN on DR-DOS has minor issues, but that's another thing entirely.)

> That's true, but the argument has little weight. An assembler which claims
> to support 16bit has to support OMF.

Maybe "fully" support 16-bit, but then again, few care about that anymore. Only things like bootsectors or pieces of kernels (written in almighty C/C++, of course) are considered 16-bit-worthy these days.

> OMF is complex because it's very old,
> created in a time when the need to reduce space did justify virtually
> everything.

In other words, "legacy". And some Windows users frown on legacy. (Good thing for them that AMD64 kicks out 16-bit, then.)

> But hey, no one did claim that writing an assembler is
> pure fun. There are always tasks which are boring and dull. The
> difference between a hobby project and a tool of professional quality is
> that the "boring" things have been done as well in the latter case.
FASM is used commercially by some people / compilers, just not for .OBJ obviously. And having Agner's OBJCONV (sorely needed for a long time) only gives yet another excuse for him not to implement it.

In fact, to convince him otherwise, we'd have to come up with an actual need or reason that's pretty good. (He did give in to vid and add "-d" due to strong reasoning and a real-world test case.)

> > How is it a disadvantage?
>
> Asm is less portable. An assembler is among those kind of tools where the
> higher degree of portability of C is a REAL advantage.
Although true, a portable x86 assembler that can run on non-x86 targets is of low use, AFAIK. At least, if you're writing x86 assembly, you may as well have an x86 box around (or emulator). NASM is now in C99, which actually limits its portability a tad (although thanks to GCC being everywhere, not as bad as it could be).

BTW, don't forget that FASM runs on more OSes than any other x86 assembler I know of. ;-)

EDIT: How did you compile JWasm for Linux? I had issues with OpenWatcom targeting Linux. :-/

> A second disadvantage is that a self-compiling tools can worsen the effect
> of undetected bugs. If a buggy tool is used for compilation, pretty strange
> effects are likely to occur, sometimes very hard to fix.
True, but FASM has been fairly well tested by users at the forum. And it doesn't use every high-level-ish feature in its own source, so it's relatively straightforward to assemble (i.e. the basics are probably more sound than the more complex stuff and thus less prone to error).
DOS386

02.01.2009, 10:39

@ Japheth
 

FASM can't brew (!) OMF ".OBJ" files OBJCONV port it away

Post reply

Rugxulo wrote:

> And having Agner's OBJCONV (sorely needed for a long time) only gives
> yet another excuse for him not to implement it.
Does it really help ??? How do you use it to get 16-bit OMF from FASM ?

> OMF is really only necessary for linking between HLLs and assembly
That's how I also see the thing ...

> Linker can be useful/necessary if no HLLs are involved at all.
Closed source pre-brewed LIB then.

> They are even useful if there's just a single module to be linked to a binary.
Please explain how. How half-done work (OBJ) can be better then fully done (EXE ready to run/crash) ?

> Asm is less portable. An assembler is among those kind of tools where the
> higher degree of portability of C is a REAL advantage.
I see no point in porting JAWASM or FASM to some 64-bit only BIG endian CPU ... but feel free to do :-D

> A second disadvantage is that a self-compiling tools can worsen the effect
> of undetected bugs. If a buggy tool is used for compilation, pretty strange
> effects are likely to occur, sometimes very hard to fix.
This assumes that you have many very mature C compilers available ... and even then, FASM's selfcompiling work is easy to check and debug.

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

Homepage

Germany (South),
02.01.2009, 11:14

@ DOS386
 

FASM can't brew (!) OMF ".OBJ" files OBJCONV port it away

Post reply

> > Linker can be useful/necessary if no HLLs are involved at all.
>
> Closed source pre-brewed LIB then.
No. Just have a look at the RxDOS project for example, which consists of some dozens of assembly modules.

> > They are even useful if there's just a single module to be linked to a
> binary.
>
> Please explain how. How half-done work (OBJ) can be better then fully done
> (EXE ready to run/crash) ?
A common task for DOS linkers was to support overlays, which allowed to create binaries larger than 640 kB.

Another thing are "floating-point fixups", which were used in some 16-bit OSes to load an emulator if no FPU was present.

A linker will also allow to (re)organize and/or sort segments. This might be useful in some cases. Also, IIRC FASM doesn't allow to temporarily switch segments in "MZ-EXE mode". So code similar to this one:

mov ax,TEXT("string 1")
mov bx,TEXT("string 2")

where the macro TEXT will ensure that the strings are written into their very own segment, cannot be done equally easily in FASM in "MZ-EXE" mode.

> > Asm is less portable. An assembler is among those kind of tools where
> the
> > higher degree of portability of C is a REAL advantage.
>
> I see no point in porting JAWASM or FASM to some 64-bit only BIG
> endian CPU ... but feel free to do :-D

It's not necessarily 64bit cpus or non-x86 cpus. JWasm got a Linux binary at virtually no cost, and this might also be true for OS/2 (and to a lesser degree the Mac).

> This assumes that you have many very mature C compilers available
> ... and even then, FASM's selfcompiling work is easy to check and debug.
Quality of OW suffered several times from bugs in the tools which were used to create the final release. So it is an additional risk.

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
02.01.2009, 19:00

@ Japheth
 

I like the bin format

Post reply

> > > Linker can be useful/necessary if no HLLs are involved at all.
> >
> > Closed source pre-brewed LIB then.
>
> No. Just have a look at the RxDOS project for example, which consists of
> some dozens of assembly modules.
None of which are required if you don't have to reduce compilation time and CPU usage. My current source (which doesn't yet compile for other reasons) is written for NASM's multi-section bin format. Multiple %include directives in about 5 files bind all source files together. Compilation is now even easier because you had to link the object files in the correct order. Now you have to execute one command, once, to get all work done without any kind of complicated "makefile" or other script. (Yes, opposed to a FASM project you have to append a few options to that single command.)

> How half-done work (OBJ) can be better then fully done (EXE ready to run/crash) ?
Then again, most Real Mode DOS programs don't even need the MZ format. .COM (created by any good assembler's bin format) is fine for any program file below ~65280 Byte :clap:

---
l
Rugxulo

Homepage

Usono,
02.01.2009, 19:59

@ ecm
 

FASM lacks OMF/OBJ support (16- / 32-bit)

Post reply

> Does it really help ??? How do you use it to get 16-bit OMF from FASM ?
Oops, forgot about that. Okay, so it doesn't help there. But I think Tomasz's original viewpoint saw direct creation of .COM and .EXE as superior than requiring tons of external libraries. Then again, I also think he focused more on 386+ than 16-bit. It's not that 386 is so evil, just that people require 386 (or 486, 586, 686, etc.) for no good reason.

And sure a portable program in C is great, but sometimes portability is overrated (esp. if all you're running it on is one architecture). Or maybe it's just that C compilers still aren't as good as they should be (e.g. too slow to compile). Ironic that C is supposed to speed up development vs. assembly and yet takes a billion times longer to compile. Also, C is hardly portable (or maybe just really really hard to write truly portably, e.g. 64-bit clean, 16-bit ints, big endian, compiler quirks, etc.) A portable but slow, kludgy program is less admired than a decent non-portable x86-only one. (But obviously JWasm isn't bad, it's quite nice.) One of the reason TASM was so popular was its speed (although later versions of MASM were fast too, right?). OPTASM was supposedly pretty fast too, as was A86 (self-assembled). It's no accident that C-written assemblers are usually slower, we just don't notice these days due to fast computers. (Japheth, if you have any simple benchmarks, I'll try 'em on my 486 for you, heh.)

> Quality of OW suffered several times from bugs in the tools which were
> used to create the final release. So it is an additional risk.
And yet almost every compiler maker likes to brag that it compiles itself. The risk of hidden bugs never stopped any of them, that's for sure: GCC, FPC, FBC, GNAT, Context, CC386, various old DOS assemblers, etc. (contrary to G++ and GPC, which are written in C).

> most Real Mode DOS programs don't even need the MZ format. .COM (created
> by any good assembler's bin format) is fine for any program file below
> ~65280 Bytes
Most compilers don't output flat binary or .COM format, e.g. DJGPP or CC386 or whatever. And face it, most people use C or C++ or Pascal instead of assembly. And compilers are notorious for not making tiny code. It used to be that tiny code meant fast too but no longer. Also, 16-bit memory models were annoying to some / most, so they eagerly jumped onto the flat 32-bit model when it was introduced. 16-bit pmode of the 286 maxed out at 16 MB, which is better than 8086's not-quite 1 MB. And I don't think 99% of programmers ever desired to code in 16-bit pmode, esp. since 286s couldn't even (easily? officially? documented?) switch back to real mode, e.g. killing compatibility (only fixed in V86 w/ 386). Even in 1994, 486 computers sometimes only came with about 4 MB of RAM. 32-bit is considered easier than 16-bit in some ways (better addressing mode, bigger regs, bigger total address space).

Hope that made sense, it seems almost like an unfocused rant (must be tired, heh). :-P
ecm

Homepage E-mail

Düsseldorf, Germany,
02.01.2009, 22:36

@ Rugxulo
 

FASM lacks OMF/OBJ support (16- / 32-bit)

Post reply

> Most compilers don't output flat binary or .COM format, e.g. DJGPP or
> CC386 or whatever. And face it, most people use C or C++ or Pascal instead
> of assembly. [blah]
I addressed whether the OMF object or MZ executable format is required for 16-bit Real Mode (since 16-bit PM isn't used much) projects written in Assembly. Anyway, most HLL compilers don't output _any_ executable format directly but support only object formats or sometimes assembly source. Support of executable formats should then belong to the linker.

---
l
DOS386

04.01.2009, 11:17

@ ecm
 

FASM lacks OMF/OBJ support (16- / 32-bit)

Post reply

Japheth wrote:

> Quality of OW suffered several times from bugs in the tools which were
> used to create the final release. So it is an additional risk.
And the solution is ? Write a HLL compiler in ASM as reportedly done with Virtual PASCAL ? :lol:

cm wrote:

> I addressed whether the OMF object or MZ executable format is required for
It isn't absolutely. Just stay below 64 KiB or get around the segmenting yourself. ;-)

> since 16-bit PM isn't used much
IIRC it never really worked ...

> most HLL compilers don't output _any_ executable format
> directly but support only object formats or sometimes assembly
While I heavily prefer the latter (ASM) ... that's what makes (in this point) CC386 great ... GCC less great (AT&T or "MASM-INTEL") and OW "shitty" (no ASM at all :-( )

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

Homepage

Usono,
04.01.2009, 21:26

@ DOS386
 

FASM lacks OMF/OBJ support (16- / 32-bit)

Post reply

> And the solution is ? Write a HLL compiler in ASM as reportedly done with
> Virtual PASCAL ? :lol:
Obviously not since marcov says this is unmaintainable (as well as using proprietary crud, which is worse but was probably a sane decision at the time).

> > I addressed whether the OMF object or MZ executable format is required
> for
>
> It isn't absolutely. Just stay below 64 KiB or get around the segmenting
> yourself. ;-)
What was .OBJ originally needed for? Lack of RAM? One-pass assemblers?

> > since 16-bit PM isn't used much
>
> IIRC it never really worked ...
Tell that to OS/2 1.x. (Don't ask me why, but every dumb OS expects everyone to rewrite all their apps. Um, maybe we don't want to? Maybe that's too much trouble? Is a stable API that offensive??)

> While I heavily prefer the latter (ASM) ... that's what makes (in this
> point) CC386 great ... GCC less great (AT&T or "MASM-INTEL") and OW
> "shitty" (no ASM at all :-( )
CC386 uses its own NASM fork, which isn't too far off from GCC's "intel". GCC is 1000x more useful with Intel syntax, we're quite fortunate that they finally implemented it. I guess AT&T is more portable or historic as well as being faster to parse. (Heck, some people prefer writing AT&T style for x86 code for some odd reason.)

And OW isn't bad, directly outputting .OBJ files is probably why it's so fast. (Their "OWCC -S" POSIX compiler driver just uses WDIS.EXE to generate the .ASM anyways.)
DOS386

30.12.2008, 22:40

@ Japheth
 

FASM is superior for DOS programming

Post reply

Rugxulo wrote:

> FASM ain't the only assembler to assemble itself:
> Octasm, Wolfware, TMA, NBASM16, NGASM, A86, Intasm, XASM, Rosasm
Most of them are obsolete or toys. RosAsm is NT GUI only ( I have some bugs pending about ROS examples with HX GUI, heh ... :-| )

Japheth wrote:

> 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.
This is a fault, no doubt.

> 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.
Explain please. :hungry:

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

22.03.2009, 05:10
(edited by DOS386, 22.03.2009, 06:04)

@ Japheth
 

JWasm BANNED

Post reply

Seems that both Japheth and JWAsm got banned from the forum of King Hutch :clap:

Now at SourceForge: http://sourceforge.net/projects/jwasm

Some dead links (used to work few days ago):

http://masm32.com/board/index.php?topic=10519.0
http://masm32.com/board/index.php?topic=10872.0

Japheth wrote:

> A common task for DOS linkers was to support overlays, which
> allowed to create binaries larger than 640 kB.
Here linkers indeed might be unique but the hack is horrible ... the overlay swapping overhead (XMS, EMS, disk) eats away cca 99% of the space save achieved ... for a representative example, just check GV EDIT (bloated, and 64 KiB limit) :-(

> Another thing are "floating-point fixups", which were used in
> some 16-bit OSes to load an emulator if no FPU was present.
Maybe useful, if it works in DOS, heh :-|

> So code similar to this one:
> mov ax,TEXT("string 1")
> mov bx,TEXT("string 2")
> where the macro TEXT will ensure that the strings are written into their
> very own segment, cannot be done equally easily in FASM in "MZ-EXE" mode.
Maybe true, but I don't see any huge benefit :-|

Rugxulo wrote:

> portable, so FASM is definitely superior, IMHO.
Japheth wrote:

> 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
That FASM lacks OMF and this problem is very minor has been already overdiscussed, the more important point is that all the great-since-portable-away-from-DOS "arguments" by Rugxulo, Japheth (check a few 1000's posts in various forums) and many others are inherently invalid, because for a DOS user it's a fault if something gets ported away, not a feature. And, FASM is one of the very few things that started on DOS, later got ported away from DOS, but still have very good DOS support, and even have features ported back to the DOS version.

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

Homepage

Germany (South),
22.03.2009, 06:42
(edited by Japheth, 22.03.2009, 06:54)

@ DOS386
 

No

Post reply

> Seems that both Japheth and JWAsm got banned from the forum of
> King Hutch :clap:
I just checked this: I can login with 'Japheth', I'm not banned. The "Open Watcom Assembler" forum has been removed, yes. IIRC I did suggest that to Hutch one week ago.

> Some dead links (used to work few days ago):
>
> http://masm32.com/board/index.php?topic=10519.0
> http://masm32.com/board/index.php?topic=10872.0
I'm sure you know the reason behind posting dead links ...

> Here linkers indeed might be unique but the hack is horrible ... the
> overlay swapping overhead (XMS, EMS, disk) eats away cca 99% of the space
> save achieved ... for a representative example, just check GV EDIT
> (bloated, and 64 KiB limit) :-(
Let us both continue to believe what we want to believe!

> > So code similar to this one:
> > mov ax,TEXT("string 1")
> > mov bx,TEXT("string 2")
> > where the macro TEXT will ensure that the strings are written into
> their
> > very own segment, cannot be done equally easily in FASM in "MZ-EXE"
> mode.
>
> Maybe true, but I don't see any huge benefit :-|
Just wait and let grow your experience in assembly. Then, in a couple of years we might talk about this topic again.

> That FASM lacks OMF and this problem is very minor has been already
> overdiscussed, the more important point is that all the
> great-since-portable-away-from-DOS "arguments" by Rugxulo,
> Japheth (check a few 1000's posts in various forums) and many
> others are inherently invalid, because for a DOS user it's a
> fault if something gets ported away, not a feature. And, FASM is
> one of the very few things that started on DOS, later got ported away from
> DOS, but still have very good DOS support, and even have features ported
> back to the DOS version.
There's a problem with posting such nonsense: some members might regard it as an insult for their intellect. OTOH there's virtually no chance that anyone will buy your "argument". Bad chance-risk ratio!

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
22.03.2009, 11:49

@ Japheth
 

Overlay swopping and segment macros

Post reply

> > Here linkers indeed might be unique but the hack is horrible ... the
> > overlay swapping overhead (XMS, EMS, disk) eats away cca 99% of the
> space
> > save achieved ... for a representative example, just check GV EDIT
> > (bloated, and 64 KiB limit) :-(
>
> Let us both continue to believe what we want to believe!
I'm currently writing some simple swapping code (for RxCMD). It does its thing in about 2 KiB, where 256 byte are reserved for the swap method specific code (XMS, HMA, temp. file, %COMSPEC% file). This leaves at least 60 KiB in the same segment which could be swapped in and out if used for overlay management. (So, yes, I agree to Japheth.)

> > > So code similar to this one:
> > > mov ax,TEXT("string 1")
> > > mov bx,TEXT("string 2")
> > > where the macro TEXT will ensure that the strings are written into
> > their
> > > very own segment, cannot be done equally easily in FASM in "MZ-EXE"
> > mode.
> >
> > Maybe true, but I don't see any huge benefit :-|
>
> Just wait and let grow your experience in assembly. Then, in a couple of
> years we might talk about this topic again.
Well, it makes many things easier, but I didn't yet get a case where I couldn't avoid it. (If you use OMF object file output it works with NASM multiline macros I think. Not sure about multi-section binary output.)

---
l
Rugxulo

Homepage

Usono,
27.03.2009, 17:00

@ Japheth
 

No

Post reply

> > Seems that both Japheth and JWAsm got banned from the forum of
> > King Hutch :clap:
>
> I just checked this: I can login with 'Japheth', I'm not banned. The "Open
> Watcom Assembler" forum has been removed, yes. IIRC I did suggest that to
> Hutch one week ago.
Um, why?? :confused:
Japheth

Homepage

Germany (South),
28.03.2009, 07:11
(edited by Japheth, 28.03.2009, 07:30)

@ Rugxulo
 

No

Post reply

> > Watcom Assembler" forum has been removed, yes. IIRC I did suggest that
> to
> > Hutch one week ago.
>
> Um, why?? :confused:
It was the wrong place. Why should someone who wants to report a bug for JWasm have to register on a forum which is intended for Masm32/Windows only?

---
MS-DOS forever!
Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 235 users online (1 registered, 234 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum