Hi, I have writen my TSR application, but it's working in strange mode, at least for me...

After TSR is installed it services INT 9H interrupt, so when i press key it should send "beep" sound (ah=2,dl=7,int 21h ), but it's only working on the same session of cmd.exe with programs that reads keys only.

I mean that after i install my tsr nothing will happen (no "beep" sound) until i won't run application in the same cmd.exe session that reads keys (ah=0, int 16h). If no application is running that read keys and i will press keys on this cmd.exe session then nothing will happen, why ? Is there some kind of seperated space between cmd.exe session and windows that is only working while application is executed by cmd.exe ?

Would command.com be helpful ?
Posted on 2012-06-02 05:55:41 by hElllk
cmd.exe is not DOS.
Your TSR is a DOS program, which triggers Windows to start it inside the NTVDM. Your int 9h will be hooked inside that NTVDM instance, but only for the lifetime and scope of that instance.

command.com can't help you there, because it has the same problem: it is run inside an NTVDM instance.

I think you need to read up on what Windows NT is. It's not DOS, and doesn't have anything to do with DOS (in a 64-bit version of Windows... which you should have been running anyway, it's 2012... there is no NTVDM, therefore there is no DOS/Win16 compatibility).
Posted on 2012-06-02 08:49:14 by Scali

cmd.exe is not DOS.
Your TSR is a DOS program, which triggers Windows to start it inside the NTVDM. Your int 9h will be hooked inside that NTVDM instance, but only for the lifetime and scope of that instance.

command.com can't help you there, because it has the same problem: it is run inside an NTVDM instance.

I think you need to read up on what Windows NT is. It's not DOS, and doesn't have anything to do with DOS (in a 64-bit version of Windows... which you should have been running anyway, it's 2012... there is no NTVDM, therefore there is no DOS/Win16 compatibility).


Thank's for your replay!

One more question... How is with it, that my TSR is running on "cmd.exe instance" waiting for 9H interrupts (.com application) and when i am on this:



and pressing keys, then nothing is happening (no programmed "beep signal" - ah=2,dl=7,int 21h), but when i run (.com) application with code like that:

readkey:
mov ah,0
int 16h
jmp readkey


And i will keep pressing random keys then i will hear beep sound. How is it with that ? Is cmd.exe only simulating DOS only when i run application and is there is no application then it's working as windows nt application ?

Please explain me this thing, thank you very much :)

P.S- I know that there is double beep sound, becouse of key pressed and unpressed, i know that ;)
Posted on 2012-06-02 11:45:01 by hElllk
cmd.exe is not DOS. It's a Win32 application.
DOS apps run in NTVDM, as I said. cmd.exe doesn't have a whole lot to do with it. If you start a DOS program from Explorer or such, it will start it inside an NTVDM as well. That's just how the Windows PE loader works when you start a new process.

So if you run your TSR from cmd.exe, it probably starts a new NTVDM, hooks int 9h, and then exits the NTVDM, since the TSR was the only program running inside it.
If your program doesn't exit, it works, because the NTVDM will remain alive.
If you were to start command.com, then start your TSR from there, it would also work, because the TSR would run inside the same NTVDM as command.com, and it won't exit until command.com exits. But it wouldn't be very useful, since it only works inside the command.com window.

If you want it to work system-wide, you'd have to use the Windows API to install a keyboard hook.
Posted on 2012-06-02 15:33:41 by Scali

cmd.exe is not DOS. It's a Win32 application.
DOS apps run in NTVDM, as I said. cmd.exe doesn't have a whole lot to do with it. If you start a DOS program from Explorer or such, it will start it inside an NTVDM as well. That's just how the Windows PE loader works when you start a new process.

So if you run your TSR from cmd.exe, it probably starts a new NTVDM, hooks int 9h, and then exits the NTVDM, since the TSR was the only program running inside it.
If your program doesn't exit, it works, because the NTVDM will remain alive.
If you were to start command.com, then start your TSR from there, it would also work, because the TSR would run inside the same NTVDM as command.com, and it won't exit until command.com exits. But it wouldn't be very useful, since it only works inside the command.com window.

If you want it to work system-wide, you'd have to use the Windows API to install a keyboard hook.



Well you didn't anwser my question :P But let's do it one more time... you have writen:

But it wouldn't be very useful, since it only works inside the command.com window.

I run my programs that i run cmd.exe and then go to my appliaction path (like c:\myapp) and then i enter my application name to run it in cmd.exe window (like press myapp.com and enter :) ). Well my question was about programs in cmd.exe / command.com.

First i run TSR with int 9h interrupt taking and then to hear "beep sound" made by "ah=2,dl=7,int 21h" i need to run application that read keys "ah=0/int16h in loop" becouse pressing keys and writting anything in cmd.exe window won't make "sound beeping". After second application is up (with loop reading keys - ah=0,int16h) then i hear beep while pressing keys, why that happening only when second program runs and not while cmd.exe window is active and i am writing on it / pressing keys while its active ?


Anyway my program works in cmd.exe but crashes in command.com - tsr, thats wired if cmd.exe = command.com
Posted on 2012-06-02 15:56:10 by hElllk
cmd.exe is NOT command.com!
Posted on 2012-06-03 04:52:30 by Scali

cmd.exe is NOT command.com!


Well but I've read a little and I've found out that it's behavior while running .com application should be the same but it's not, why ? My TSR is working when opening from cmd.exe, but crashes when opening from command.com, why ?

And one more time about NTVDM. NTVDM is being "activated" only when i run my .com application in cmd.exe and other way it's working as normal cmd.exe windows nt application, yes ?
Posted on 2012-06-03 06:30:22 by hElllk
AFAIK, cmd.exe is 32-bit code, command.com is 16-bit code (although not a .com file, despite the name). Thus, cmd.exe might give you a new virtual machine for every 16-bit app you run, where command.com might start a vm to run itself and use the same one for... any apps it runs before it crashes.

As I recall, it isn't considered "reliable" to use a dos interrupt in a TSR. To do so "safely", you had to check the "dos idle" flag and make sure you weren't in a "critical error handler".  Quite complex to do it "right". I don't know if that's your problem - perhaps you do all that. A TSR that beeps the speaker using ports, or something that doesn't depend on dos interrupts might be easier. As Scali points out, it's 2012 - you might want to put your time into learning the modern API rather than delving into the intricacies of dos TSRs.

Best,
Frank

Posted on 2012-06-03 07:00:34 by fbkotler

AFAIK, cmd.exe is 32-bit code,


Or 64-bit code.


command.com is 16-bit code (although not a .com file, despite the name). Thus, cmd.exe might give you a new virtual machine for every 16-bit app you run, where command.com might start a vm to run itself and use the same one for... any apps it runs before it crashes.


Indeed.


As Scali points out, it's 2012 - you might want to put your time into learning the modern API rather than delving into the intricacies of dos TSRs.


Yes, not sure what your goal is, but writing something that only runs within an emulated legacy environment (which is no longer available in 64-bit versions of Windows that have been around since 2005) will be very limited indeed.
You'll never get it to beep for Windows applications that way (as you already found out with cmd.exe itself).

You're not hooking the actual system int 9h obviously (no modern OS would ever allow a regular user program that level of control. Merely the emulated int 9h inside the VM.
Posted on 2012-06-03 08:12:03 by Scali

And one more time about NTVDM. NTVDM is being "activated" only when i run my .com application in cmd.exe and other way it's working as normal cmd.exe windows nt application, yes ?


As I tried to say earlier, cmd.exe doesn't have anything to do with that really.
cmd.exe just calls CreateProcess() (or similar API) to start any executable from the commandline. CreateProcess() is the one responsible for starting NTVDM. This works the same regardless of whether cmd.exe calls it, or any other application.
cmd.exe itself is ALWAYS Windows application. It doesn't have anything to do with the DOS emulation.
Posted on 2012-06-03 08:21:36 by Scali
Thank's guys! Now all (let's say "all" :D) is clear for me, thank you very much!!! I really appreciate for this information and your help, I know it's "oldschool", but I need it, thank you very much!!!
Posted on 2012-06-03 09:23:20 by hElllk