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!?
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.
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?
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.
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...
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.
QuoteMaybe 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 ...
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.
; 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...
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.
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...
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.
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)...
Let's have a look - zip your code up and post it
Please excuse the German commenting.
Also, its slightly messy in there.... :red
[attachment deleted by admin]
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.
Oh my god, I guess you were right...
I've fixed it now.
But that still doesn't explain why on earth when run inside dosbox, the code works.
Either the return command isn't correctly executed in dosbox's implementation, or maybe this is a common error and dosbox compensates for it, either way I would really like to know!
Any ideas??
I think the problem is that your code is depending on a behavior that is unique to DOSBox. Function 2 is from the first version of MS-DOS/PC-DOS, is documented as having no return value, and has since been superseded by function 40h, which does have a return value. I seem to recall that the later versions of MS-DOS, instead of retaining the superceded functions, replaced them with stubs that would redirect the function call to the newer function. In any case, no return value does not equate to AL preserved. Under Windows 2000, this code corrects the problem:
; Erstes Zeichen Ein/Ausgabe, Programmverzweigung steuern, Abbruch?
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
PUSH AX
mov ah,2h
mov dl,020h ; Leerzeichen in DL und
int 21h ; ausgeben
POP AX
ret
QuoteI seem to recall that the later versions of MS-DOS, instead of retaining the superseded functions, replaced them with stubs that would redirect the function call to the newer function
And Dosbox of course would not do that, for maximizing its compatibility and implement the old function!?
Gentleman, we have a winner :bg
I solved the problem by just adding the space after storing al in a seperate register, not before.
Case closed. Thanks for all the helpful input!