Compatibility between 'real' dos and winXP's cmd-line for simple apps[solved]

[hungerTom]

Hello!? I'm new here, quite human, and I have a slight problem.

I'm studying CS, and currently doing a course on assembly language.
My tutor being rather 'old school' thinks we should learn by writing 16bit dos assembly code for masm 6.0.  :8)
No 'real' problem there, just the fact that the computers at uni are loaded up with winXP. So our 'dos' is actually just the cmd-line that comes with 32bit XP.
He actually expects us to write our code with EDIT, in fullscreen, on 21inch screens...well anyway, I don't run MS-Windows at home, just linux. So I was using a dos emulator to do my work.
At first I tried dosemu, which sadly does not support CODEVIEW, the debugger that we need to use, so I switched to dosbox and I got my work done, so it seemed...

I went back with my completed assignments, and attempted to run them(and demonstrate them to my tutor), using window's cmd-line.
Guess what, they failed. I mean, they ran, but they produced unexpected results, or behaved oddly.
These aren't any complex tasks, just things like converting ascii-codes to hex, or decimals to hex, or reading/writing some files and things like that. Plain old INT21H stuff.

My question, are there real basic things that a 'real' dos (emulated by dosbox/dosemu) can do, which window's cmd cant?
I mean, is there some kind of guideline I can align my code against, so that it will run in the windows environment, without having to painfully debug every shift and move operation!?    

[MichaelW]

Hello hungerTom,

I have never had a problem with "plain old INT2H stuff" under any version of Windows from 95 to XP.  NT/2000/XP will not allow low-level access to the hard disk drive, and might possibly restrict access to certain system files, but normal file operations, and certainly data conversions and similar, should work the same as they work under the later versions of MS-DOS.

[hungerTom]

Hmm, well maybe it is dosbox that messes things up, I wouldn't know.
I know that certain keyboard keys are mapped to different ascii codes, as one assignment was to dump the hexvalue/ascii code of keys inputted.
Also, in a different assignment we needed to convert a given hex-number (entered via the keyboard at runtime) to it's decimal value.
When running, it would give something around 4xtimes of the correct number.
Could this somehow be related?

[FORTRANS]

Hello hungerTom,

   I write code in DOS for DOS, running DOS.  And I code in DOS
running Windows 2000 and XP for the "Command Prompt".  And
in DOS running OS/2 for its VDM.  I do not see what you are
describing.

   Windows broke some programs, but that was with the command
line arguments being passed to the program when it runs.  Oh,
and some BIOS functions no longer working.  If the keyboard
codes are being remapped, I have not seen that at all.  Go to

http://hplx.pgdn.de/

He has a good Scancode program to report (what else) the scan
codes.  His LXPIC is a good DOS image viewing program.  And
running it should be a very basic test of compatibility.  And you
can check if the DOS functions return the same key code as the
BIOS functions.

HTH,

Steve N.

[hungerTom]

Hmm, I'll investigate this further over the weekend.
I was just wondering if there were any such issues, thus saving me some work  ::)

I'll have a look at the site, maybe it'll help track down the glitch.
Also, I have an old laptop, with DOS 6.22 installed, I'll fire it up to see if the problem is in my code, or in Dosbox's interpretation thereof...

[BlackVortex]

Well, dosbox is an emulator, it emulates a virtual machine. So technically you're running your code incisde the virtual machine, not your"own", "real" machine.

It's like running your program on a different machine, with different hardware and OS. Maybe it emulates its own virtual keyboard.

[hungerTom]

Maybe it emulates its own virtual keyboard.

It certainly does. I use a German keyboard, and normally, without loading a different keyboard model within dosbox, I would get a false key mapping.
By now I suspect that my problems are down to my program getting the wrong values for the key-presses, thus using different hex values than I think it is using when calculating a decimal ...

[hungerTom]

After a long time, I've finally managed to look into the problem again. As I wrote above, I assumed my compatibility issues had something todo with the key-map that was in use.
I now know, that this has nothing todo with my problem.

To summarize:
I used dosbox for 'development'. My Programs ran fine.
I then tested them under XP. They failed.
I've by now also tried MS-Dos 6.22 (both on a real pc and via virtualisation), win98, and dosemu. The Program always failed.

I've now been going through the source and have discovered the problem, at least I think so.
The Program simply reads 3 inputted keys, echoes them on screen, and then dumps their hexvalues.
A space is also added between the individual hexoutput.
the problem is, that instead of getting the expected hexnumber, I alsways just get '20', which is a space.

Code Select Expand


; shortend code
call    b_out
mov     dl,020h     ; Space gets pushed into dl
int     21h               ; and gets onto the screen

b_out:
mov     ah,2h  ;Funktion 2, the value is already stored in dl
int     21h         ;and should get pushed onto the screen
ret                   


If I take away the output of a space, the correct value is displayed. Using spaces, the correct value only gets displayed in dosbox.
I find this very strange, and I would really like to understand why dosbox never complained...

[tenkey]

It looks like you're expecting AX to remain unchanged after an INT 21H. I've never seen real DOS code that makes that assumption.

[hungerTom]

But shouldn't the value in dl under b_out be outputted first??

As it is, its just skipped, and after the return statement 'replaced' by a space...
It makes no difference if I add another  mov  ah,2h , after the call to b_out, and indeed the full code has that statement present...

[drunk_sinsi]

Are you using AL to store your value and expecting it to be the same after INT 21? For function 2, AL returns with the last character output, which would be a space.

[hungerTom]

As far as I know, the function 2 expects the value to output onto the screen to be in dl.
In this case this should be the hexcoded ascii value of a key pressed beforehand, followed by a space, and some more keycodes.
The hexvalue for the first key is already in dl in my example, the full b_out does the necessary conversion, and then calls function 2 for the output.
This works fine, but not if I immediately afterwards also want to output a space.
Dosbox for some reason gives the expected output, 'real' dos-es do not... my hexvalue just gets 'replaced' by the space (20)...

[drunk_sinsi]

Let's have a look - zip your code up and post it

[hungerTom]

Please excuse the German commenting.
Also, its slightly messy in there....  :red


[attachment deleted by admin]

[sinsi]

Code Select Expand


c1_in:  mov     ah,8h       ; Fkt. 8: Tastatur-Zeicheneingabe ohne Echo
        int     21h         ; eingegebenes Zeichen in Register AL
        cmp     al,01Bh     ; Wenn ESC
        jz      pEnde       ; Programmm abbrechen
        mov     ah,2h       ; Fkt. 2: Einzelzeichen Ausgabe
        mov     dl,al       ; Eingabezeichen in DL und
        int     21h         ; ausgeben --------> on return, your AL is still the same because of the "mov dl,al" above
        mov     ah,2h
        mov     dl,020h     ; Leerzeichen in DL und
        int     21h         ; ausgeben --------> on return, your AL has been trashed - last char output was 20h <-----------
        ret

As I said in a previous post, DOS function 2 will return the character printed in AL - this overwrites your value from function 8.
You need to save it somewhere before you use function 2.