DOS ain't dead

Japheth released DEBUG 1.13 2008-Feb-27

http://www.japheth.de/

Also mirrored here:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/

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

Bug: doesn't decode UD2 instruction ($0F,$0B)

Suggestion (seems not present in this form, at least in 1.12): edit memory: display existing byte, and allow to replace it with a new one, or keep if no new value entered

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

> Bug: doesn't decode UD2 instruction ($0F,$0B)

That's not a bug, that's a missing feature. It also doesn't decode MMX, SSE, ...

> Suggestion (seems not present in this form, at least in 1.12): edit
> memory: display existing byte, and allow to replace it with a new one, or
> keep if no new value entered

I don't understand what you want, but before I consider to do anything please resolve my little FASM riddle first:

http://www.bttr-software.de/forum/forum_entry.php?id=3378

(without using "dirty hacks")

---
MS-DOS forever!

> Suggestion (seems not present in this form, at least in 1.12): edit
> memory: display existing byte, and allow to replace it with a new one, or
> keep if no new value entered

debug MYFILE.COM
e 100

"Space" will skip/ignore the byte and go to the next one.
"54" will put "54" in place of current byte.
"Enter" will go back to the "-" prompt.

Is this what you meant?

P.S. Japheth, no idea, just PM or e-mail Tomasz directly.

> P.S. Japheth, no idea, just PM or e-mail Tomasz directly.

I'd prefer you, the FASM adorers, to solve it. It's you who permanently speak about how fast, great and superior FASM is ...

---
MS-DOS forever!

> I'd prefer you, the FASM adorers, to solve it. It's you who permanently
> speak about how fast, great and superior FASM is ...

Tomasz has solved it for you finally: http://board.flatassembler.net/topic.php?t=8338

the correct FASM version is:

macro defext name
{
    extrn name
    match realname,name
    \{ public __imp_\# realname
       __imp_\# realname dd name \}
}

---
MS-DOS forever!

> I'd prefer you, the FASM adorers, to solve it. It's you who
> permanently speak about how fast, great and superior FASM is ...

If I ate roast beef 11 times in my life, would you say I was permanently eating roast beef?

But seriously, FASM is great, but the whole preprocessor/assembler difference and the ultra-powerful macros can be a bit mind-boggling.

IMO, the guy (Tomasz) really is a genius (officially, a mathematician).

> Tomasz has solved it for you finally:
> http://board.flatassembler.net/topic.php?t=8338

So what program was this intended for anyways? (Just curious.)

> But seriously, FASM is great, ...

I know. FASM is great, DGPJJ is great, ... I'm used to buy everything what's advertised because I'm such a smart guy ...

> but the whole preprocessor/assembler difference and the ultra-powerful macros
> can be a bit mind-boggling.

IIRC I already asked, but cannot remember your response: did you ever write a non-trivial FASM program? Because, IMO, someone who did that should be familiar with the "match" directive.

> So what program was this intended for anyways? (Just curious.)

It's a small tool which creates tiny modules for IMPHLP.LIB (contained in hxdev) by launching an assembler "several" (currently 1500) times. I knew that FASM would be the best tool for that because it includes the very minimum into the COFF output. The imphlp.lib in hxdev v2.14 was created with NASM, size is about 600kb. With FASM, the size will shrink to about 480 kB.

---
MS-DOS forever!

> I know. FASM is great, DGPJJ is great, ... I'm used to buy everything
> what's advertised because I'm such a smart guy ...

You don't have to buy 'em, they're free. I understand that you prefer MSVC over DJGPP, but it's a much larger download, not open source, but I guess has better optimizations? (And Intel is reportedly even better, but AFAIK, only their Linux version is free for non-commercial use.)

I didn't say FASM was perfect, but it has a lot going for it. You of course are free to use whatever you want. It is not my intention to bombard you with "adverts".

> IIRC I already asked, but cannot remember your response: did you ever
> write a non-trivial FASM program?

Does my tiny attrib clone count? LFN dir? If not (and probably not, oh well), then not really. I mostly write tiny utils for my own use, nothing fancy or ground-breaking, sorry to offend or disappoint you.

> Because, IMO, someone who did that
> should be familiar with the "match" directive.

I'm only superficially aware of it since I've never majorly needed it. The simple "match =1, DEBUG { include 'only8086.inc' }" in the manual is the most I've ever used.

> It's a small tool which creates tiny modules for IMPHLP.LIB (contained in
> hxdev) by launching an assembler "several" (currently 1500) times.

Yikes! Certainly doing that will be much much faster in FASM. (Even YASM is a fair bit faster than NASM.)

> Does my tiny attrib clone count? LFN dir? If not (and probably not, oh
> well), then not really. I mostly write tiny utils for my own use, nothing
> fancy or ground-breaking, sorry to offend or disappoint you.

I want to understand why you obviously love this thing. DOS386 loves it because it fully supports DOS, you might love it because you don't really know it yet ...

> Yikes! Certainly doing that will be much much faster in FASM. (Even YASM is a
> fair bit faster than NASM.)

Actually FASM is slightly slower than NASM to finish this task because it displays its "logo" 1500 times (that's why a -q option might be useful for FASM). If I redirect the displays to a file, it needs about 50% of NASM's time.

---
MS-DOS forever!

> I want to understand why you obviously love this thing. DOS386 loves it
> because it fully supports DOS, you might love it because you don't really
> know it yet ...

Open source, assembles itself (no need for a compiler to rebuild).
Fast.
Multi OS.
Multiple output formats from any version (including making .EXE w/o linker).
Nice simple IDE w/ FASM built-in for DOS w/ syntax highlighting.
Nice docs and excellent forum (IMO) with lots of examples.

I'm not saying I hate NASM or most (any?) other assemblers. But FASM is indeed pretty powerful.

> Actually FASM is slightly slower than NASM to finish this task because it
> displays its "logo" 1500 times (that's why a -q option might be useful for
> FASM). If I redirect the displays to a file, it needs about 50% of NASM's
> time.

Yeah, but if you can just redirect to NUL, why add -q just to do the same? (I mean, it's fine I guess, but the whole "no cmdline options" thingy seems to be disappearing pretty quickly ...). For now, just do that or reassemble without that part.

> Open source, assembles itself (no need for a compiler to rebuild).
> Fast.

[more ads snipped]

> Yeah, but if you can just redirect to NUL, why add -q just to do the same?

It's not "the same", it just appears to be the same.

> (I mean, it's fine I guess, but the whole "no cmdline options" thingy seems
> to be disappearing pretty quickly ...)

Yes, because it was nonsense from the very beginning and this was absolutely clear to all who are able to use their brains. It was bought just by the adorers...

---
MS-DOS forever!

> [more ads snipped]

Well, you did say "I want to know ...".

> > Yeah, but if you can just redirect to NUL, why add -q just to do the
> same?
>
> It's not "the same", it just appears to be the same.

Maybe -q would be faster for your needs (1500 times in a row!)?

> > the whole "no cmdline options" thingy seems to be disappearing
> > pretty quickly ...)
>
> Yes, because it was nonsense from the very beginning ... It was bought
> just by the adorers...

Well, the inherent idea was that there wouldn't be a billion cmdline options needed to output a specific output format. It was supposed to (and did) simplify everything and prevent errors.

<sarcasm>
Now that you've found your true love, NASM, I expect you to write 100% of everything in it.
</sarcasm>

There's room for more than one, obviously. And they don't have to all behave the same way (ahem, Octasm).

Thanks Japheth, I'm glad this is still being developed. It was really helpful in writing my game.

In FD DEBUG, when 'g' is used the segments are changed and have to be manually reset to run a program again. This does not happen in MS DEBUG.

----------------
In MS DEBUG; DS,ES,SS,CS are unchanged after using 'g':
C:\>debug test.com
-r
AX=0000  BX=0000  CX=0008  DX=0000  SP=FFFE  BP=0000  SI=0000  DI=0000
DS=147E  ES=147E  SS=147E  CS=147E  IP=0100   NV UP EI PL NZ NA PO NC
147E:0100 B402          MOV     AH,02
-g
A
Program terminated normally
-r
AX=0000  BX=0000  CX=0008  DX=0000  SP=FFFE  BP=0000  SI=0000  DI=0000
DS=147E  ES=147E  SS=147E  CS=147E  IP=0100   NV UP EI PL NZ NA PO NC
147E:0100 B402          MOV     AH,02
-g
A
Program terminated normally
-

----------------
In FD DEBUG; DS,ES,SS,CS are all changed after using 'g':
C:\>debug test.com
-r
AX=0000 BX=0000 CX=0008 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=1463 ES=1463 SS=1463 CS=1463 IP=0100 NV UP EI NG NZ NA PO NC
1463:0100 B402              MOV     AH,02
-g
A
Program terminated normally (0000)
-r
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=13E4 ES=13E4 SS=13E4 CS=13E4 IP=0100 NV UP EI PL ZR NA PE NC
13E4:0100 C3                RET
-g

Program terminated normally (0000)
-

----------------
The program I used prints 'A'
mov ah,2
mov dl,41h
int 21h
int 20h

Is this a bug or was it intentional? Thanks

> In FD DEBUG, when 'g' is used the segments are changed and have to be
> manually reset to run a program again.

No; resetting them would indeed crash the computer, or at least use DOS memory no longer occupied by this program. FD DEBUG seems to unload debugee after it terminated and then create the dummy PSP like if no debugee is loaded at all.

The different segment results in that a loaded program will get it's own environment block opposed to the DEBUG dummy PSP that shares DEBUG's environment block; most likely the environment block of the loaded program will be just there where the dummy PSP itself will be created.

---
l

> Is this a bug or was it intentional? Thanks

it's intentionally. Just reload your program with 'l' if you'd like to see the old values of the segment registers.

---
MS-DOS forever!

Here's another DEBUG clone, which also understands 386 instructions:

http://www.modest-proposals.com/Furball.htm

It's based on the v0.95 source of Paul Voita's Debug.com, but syntax changed to Masm (can be assembled with Jwasm, needs -Zm switch).

---
MS-DOS forever!

> It's based on the v0.95 source of Paul Voita's Debug.com, but syntax
> changed to Masm (can be assembled with Jwasm, needs -Zm switch).

Do you plan to develop for this and drop our good NASM DEBUG from now?

---
l

> > It's based on the v0.95 source of Paul Voita's Debug.com, but syntax
> > changed to Masm (can be assembled with Jwasm, needs -Zm switch).
>
> Do you plan to develop for this and drop our good NASM DEBUG from now?

No. But I will try it and see if some useful feature can be stolen...

---
MS-DOS forever!

> No. But I will try it and see if some useful feature can be stolen...

Good idea, indeed

---
l

There's a new version available:

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

readme: http://www.japheth.de/Debug/readme.txt

good news: some bug-fixes + a better H cmd
bad news: won't assemble with Nasm/Yasm anymore, needs Masm/JWasm. Fortunately there is NOMYSO ...

---
MS-DOS forever!

> There's a new version available:
>
> http://www.japheth.de/debxxf.html
>
> readme: http://www.japheth.de/Debug/readme.txt
>

Thanks for the update!

> "Space" will skip/ignore the byte and go to the next one.
> "54" will put "54" in place of current byte.
> "Enter" will go back to the "-" prompt.

and '-' will go back one byte.

---
MS-DOS forever!