DOS ain't dead

A new JWasm release has finally come to life:

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

It's a bugfix release, see details here: http://www.japheth.de/JWasm/History.txt

---
MS-DOS forever!

On Oct. 8, Japheth silently released JWasm 2.04b to the unsuspecting public.

Download: http://www.japheth.de/JWasm.html
Changes: http://www.japheth.de/JWasm/History.txt

Here's what caught my eye when reading the changes (obviously it's almost all bugfixes):

(2.04):
- JWASMR.EXE: setting radix to 16 made the assembler accept no numbers
anymore.
- JWASMR.EXE: freeing a PROC's local items was done with the wrong
linked list. This often resulted in an abnormal termination.
- JWASMR.EXE: v2.03 often fell into an endless loop due to an error in
fixup management for backpatching.
- SHR and SHL operator didn't reject negative shift counts. Also,
shift counts >= 64 returned compiler-dependant results.
- Djgpp variant of COFF supported ( disabled by default ).
- JWASMR.EXE: stack size increased from 16 kB to 20 kB.

Thanks for posting. You were a bit faster than me. v2.04b is most likely the final and "stable" variant of v2.04.

The JWASMR v2.04b binary is more reliable than in previous versions. A test to assemble the FD DEBUG sources ( > 11.000 lines ) with it was successful. In case you get an "out of memory" error, try to change the format from BIN to OMF - this needs less memory.

---
MS-DOS forever!

> Thanks for posting. You were a bit faster than me. v2.04b is most likely
> the final and "stable" variant of v2.04.

BTW, in case it isn't obvious ... THANKS!

A regression in v2.04-v2.04b made this update necessary.

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

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

---
MS-DOS forever!

> v2.04b is most likely the final and "stable" variant of v2.04
> The JWASMR v2.04b binary is more reliable than in previous versions

Nope:



Bugs:

1. JWASMR misscompiles the "magic" jump in DOS3.ASM so it securely hangs (see shot) oops maybe this one is fixed in 2.04c

2. There are some aligns inside the binary and they contain random garbage rather than ZERO's. Is it documented anywhere that the aligns are expected and how they are supposed to work ?

3. The stuff is messed up inside the executable, or, more likely, fine in the executable but messed up in the source. Is this effect, if not considered as bug, documented anywhere ?

4. It produces garbage if -mz is not specified (see shot). Is this effect, if not considered as bug, documented anywhere ?

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

> 2. There are some aligns inside the binary and they contain random garbage
> rather than ZERO's. Is it documented anywhere that the aligns are expected
> and how they are supposed to work ?

Yes. These may be filler bytes used for segment alignment. They aren't written, there's just a file positioning, so the values may be OS-dependent.

This is expected behavior.

> 3. The stuff is messed up inside the executable, or, more likely, fine in
> the executable but messed up in the source. Is this effect, if not
> considered as bug, documented anywhere ?

I don't understand what you're talking about.

> 4. It produces garbage if -mz is not specified (see shot). Is this
> effect, if not considered as bug, documented anywhere ?

I don't understand what you're talking about. I see nothing peculiar in the "shot".

---
MS-DOS forever!

> Yes. These may be filler bytes used for segment alignment. They aren't
> written, there's just a file positioning, so the values may be OS-dependent

Align by sparse seek ?

> I don't understand what you're talking about.

"welcome in protected-mode" is not at the same place for example.

> I don't understand what you're talking about. I see nothing peculiar in the "shot"

It brews "DOS3.OBJ" only and this behavior is nowhere documented.

3 more (sub-sub-minor):

-

     mov dl,al
     mov ah,2


works but there is a better way:


     mov dh, 2
     xchg eax, edx


- page still says 2.04b

- there is no "use32" in the code ... oh well maybe this is also a feature

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

> - there is no "use32" in the code ... oh well maybe this is also a feature

... or maybe ignorance?

> > - page still says 2.04b

That's indeed a bug. Thanks!

However, please do me a favor: test some other software! The signal-to-noise ratio of your JWasm bug reports is too low for my taste.

---
MS-DOS forever!

EZEDIT 2.0 (nice 4 kb DOS text editor) can be assembled with JWasm (with a few minor changes). I didn't exhaustively test it, but it seems to still work!

@echo off
REM http://craighessel.webs.com/
if not exist ezedit.asm goto end
sed -e "s/REPEAT/REPEET/g" -e "s/Enter/Entre/g" -e "s/CircBuf\[/byte ptr &/" ezedit.asm >ez.asm
REM http://www.japheth.de/JWasm.html
jwasmr -bin -FoEZ.COM ez.asm
:end

N.B. rr, that means your Links page has some bogus Geocities links (VAL '99, MUTT, PIX, NASM-IDE).

P.S. Japheth, is there any huge reason why your URL is case sensitive? More specifically, why isn't there are least a simple redirecting page called "jwasm.html" -> JWasm.html??

>
> sed -e "s/REPEAT/REPEET/g" -e "s/Enter/Entre/g" -e "s/CircBuf\[/byte ptr
>

I guess the last of the three changes ( CircBuf requiring a "byte ptr" prefix ) is a bug in JWasm.

> P.S. Japheth, is there any huge reason why your URL is case
> sensitive? More specifically, why isn't there are least a simple
> redirecting page called "jwasm.html" -> JWasm.html??

It's a simple barrier to keep all those out who are easily distracted and have a vague interest only.

---
MS-DOS forever!

> N.B. rr, that means your
> Links page has some bogus
> Geocities links (VAL '99, MUTT, PIX, NASM-IDE).

Plus 20 more broken links.

---
Forum admin

> or maybe ignorance?

Either it is not documented (then it would be a documentation bug), or it is documented but I failed to find it (then it would have to be ignorance)

> However, please do me a favor: test some other software!

I will

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

> I guess the last of the three changes ( CircBuf requiring a "byte ptr"
> prefix ) is a bug in JWasm.

BTW, not sure this is a bug or not, but just FYI:

invadr11.zip (TASM source, which I'm testing here)
inv2fasm.zip (just mentioned for completeness; not strictly FASM, just includes sed script to convert from ArrowASM- / A86-friendly src)

> (original source, with no changes)
> INVADERS.ASM(2028) : Error A2074: Segment, group or segment register expected
> INVADERS.ASM(2029) : Error A2074: Segment, group or segment register expected



Comparing files INVADERS.ASM and INVADERS.NEW
***** INVADERS.ASM
;-------------------------------;
; 9k Space Invaders Version 1.1 ;
***** INVADERS.NEW
; http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/gamesrc/invadr11.zip
; jwasm -Zm -bin -Fo inv.com invaders.asm
;-------------------------------;
; 9k Space Invaders Version 1.1 ;
*****

***** INVADERS.ASM
                        MOV     StoreAX,AX
                        MOV     AX,40:[01ch]
                        MOV     40:[01ah],AX
                        MOV     AX,StoreAX
***** INVADERS.NEW
                        MOV     StoreAX,AX

                        ;MOV     AX,[40:01ch]
                        ;MOV     [40:01ah],AX
                        push es
                        mov ax,40h
                        mov es,ax
                        push word ptr [es:01Ch]
                        pop word ptr [es:01Ah]
                        pop es

                        MOV     AX,StoreAX
*****


After that, it seems to work. (Both YASM -ptasm and WASM -zcm=tasm fail miserably here. Hmmm, seems WASM has problems with "dec/inc" instructions here. But neither has problems assembling my old 2004 cleanup above, thankfully.)

> MOV AX,40:[01ch]
> MOV 40:[01ah],AX

Yes, 40:[01Ch] isn't a valid expression in Masm-syntax.

Tasm swallows it without complain, but I guess it is nevertheless a bug, because the resulting COM file still "beeps".

> After that, it seems to work.

I additionally changed:


-Exit:                  CALL    RemoveNewInt9
+Exit::                 CALL    RemoveNewInt9
-StartGame:             CALL    ResetGame
+StartGame::            CALL    ResetGame
-RedrawBunkers:         CALL    DrawBunkers
+RedrawBunkers::        CALL    DrawBunkers


to make the -Zm switch unnecessary.

---
MS-DOS forever!