DOS ain't dead

Rayer asked on DJGPP forum whether is possible to allocate buffer in size of few MB and shared it between DOS and WinXP applications.

I know know but I've found a trick how to call Windows functions from DOS programs. (Windows must be running, of course)
Look here: http://www.ragestorm.net/tutorial?id=27
and here: http://www.ragestorm.net/sample?id=94

Another example is sound library for QBasic called DS4QB2
http://www.qbcafe.net/qbc/english/download/qbasic_library/sound_music.shtml

---
DOS-u-akbar!

Yes. Win32 dlls running in a NTVDM are called VDDs. It's "officially" documented how to load and call VDDs from DOS, there is no hack or secret involved. For example, FD Debug (DEBUGX.COM) also uses a VDD to make sector read/write commands work in WinXP.

---
MS-DOS forever!

Hehe I see most of guys here visits DJGPP group :)

Yes VDD may be a way but it is little bit a voodoo magic for me. Is it possible to develop VDDs in mingw32 and DOS caller in DJGPP without using asembler? But as I saw from tutorial, this VDD calling is for realmode so this mean that I cannot transfer my buffer in one time and having to use movedata() to copy it from DJGPP PM to DOS RM and then call a VDD to transfer this block. This will make some overherad.
Better would be if I can call VDD with my selector:offset pointing buffer in PM.

---
DOS gives me freedom to unlimited HW access.

> Hehe I see most of guys here visits DJGPP group :)
>
> Yes VDD may be a way but it is little bit a voodoo magic for me. Is it
> possible to develop VDDs in mingw32 and DOS caller in DJGPP without using
> asembler?

Yes. A VDD is a normal Win32 dll.

> But as I saw from tutorial, this VDD calling is for realmode so
> this mean that I cannot transfer my buffer in one time and having to use
> movedata() to copy it from DJGPP PM to DOS RM and then call a VDD to
> transfer this block. This will make some overherad.
> Better would be if I can call VDD with my selector:offset pointing buffer
> in PM.

BOPs also work in protected-mode. I use it in the self-written debugger debxxf. There's a bug in NTVDM, however, addresses must be FAR16, that is, the offset part must be 16bit. So if used in DGPJJ some dpmi selector magic might be needed.

---
MS-DOS forever!

Do you have some short PM call example, please?

---
DOS gives me freedom to unlimited HW access.

> Do you have some short PM call example, please?

Sorry, there are no samples and no tutorials. But it's done in the following apps, available with source on japheth.de:

- FD Debug (Nasm)
- hxntvdm (Masm)
- idecheck (Masm)

In all three apps the VDD is called in protected-mode. hxntvdm is small, just 500 lines. In idecheck, which uses the flat memory model, the "selector magic" mentioned previously must be used - so it is slightly more difficult to understand.

---
MS-DOS forever!

I tried a small experiment in DJGPP.
I made a simple program which dumps CS, DS, SS decriptors and show its bases. I run it under NTVDM and the result was:

CS: 1A7h, base = 029E0000h, limit = 9FFFFh, granularity = 1B
DS: 1AFh, base = 029E0000h, limit = 9FFFFh, granularity = 1B
SS: 1AFh, base = 029E0000h, limit = 9FFFFh, granularity = 1B
DOS_DS: 1AFh, base = 00000000h, limit = 0010Fh, granularity = 4096B
MSGPTR: 118E0h

I have placed magic string at offset 118E0.
Parallel with this program I launched Read & Write utility and look at physical
assress equal to base+offset but no magic string there. I searched through phys memory and found it much higher somewhere over 50000000, 60000000 and more in some instances. Hm is it messed up due to paging? Normally I would expect that segment descriptor base address is physical address... So seems a VDD is only possible way (except that damn ramdisk :)

EDIT:
Grrr, I ran muliple instances of my program and all has reported 029E0000h same base, it's impossible to be physical address.

EDIT2:
Under Win98 each instance of program got unique base addres but this is also not true physical address

CS: A7h, base = 84E9F000h, limit = 9FFFFh, granularity = 1B
DS: AFh, base = 84E9F000h, limit = 9FFFFh, granularity = 1B
SS: AFh, base = 84E9F000h, limit = 9FFFFh, granularity = 1B
DOS_DS: AFh, base = 00000000h, limit = 0010Fh, granularity = 4096B
MSGPTR: 118E0h

---
DOS gives me freedom to unlimited HW access.

> I tried a small experiment in DJGPP.
> I made a simple program which dumps CS, DS, SS decriptors and show its
> bases. I run it under NTVDM and the result was:
>
> CS: 1A7h, base = 029E0000h, limit = 9FFFFh, granularity = 1B
> DS: 1AFh, base = 029E0000h, limit = 9FFFFh, granularity = 1B
> SS: 1AFh, base = 029E0000h, limit = 9FFFFh, granularity = 1B
> DOS_DS: 1AFh, base = 00000000h, limit = 0010Fh, granularity = 4096B
> MSGPTR: 118E0h
>
> I have placed magic string at offset 118E0.
> Parallel with this program I launched Read & Write utility and look at
> physical
> assress equal to base+offset but no magic string there. I searched through
> phys memory and found it much higher somewhere over 50000000, 60000000 and
> more in some instances. Hm is it messed up due to paging?

Yes, addresses in GDT/LDT are linear addresses. Physical addresses are "used" by CR3, page dirs and page tables.

> Normally I would
> expect that segment descriptor base address is physical address... So seems
> a VDD is only possible way (except that damn ramdisk :)

Why do you suddenly talk about physical addresses? You won't be able to get physical addresses with a VDD.

---
MS-DOS forever!

> Yes, addresses in GDT/LDT are linear addresses. Physical addresses are
> "used" by CR3, page dirs and page tables.

Well, in fact I don't need true physical address but address which will have same meaning inside DJGPP program and outside in win32 app. So when I will create descriptor with same linear base in win32 app and will reach the same data as DJGPP prog. But as I saw NTVDM has assigned same linear address for multiple instances it will not work. If I use this linear address for descriptor inside win32 app it will point probably to somewhere else. Maybe it would work under w9x.
Anyway I need to exchange some pointer to data which will work for both djgpp prog and win 32 app. As I understand calling VDD allows me to exchange data in registers (so maybe pointers) but how to get pointer usable for both sides? Or does NT kernel have some special functions to read memory inside NTVDM DPMI space? I would imagine somethinkg like ntvdm_movedata(UINT32 ntvdm_linear_address, UINT8 *buffer, UINT32 size);

---
DOS gives me freedom to unlimited HW access.

> Well, in fact I don't need true physical address but address which will
> have same meaning inside DJGPP program and outside in win32 app. So when I
> will create descriptor with same linear base in win32 app and will reach
> the same data as DJGPP prog. But as I saw NTVDM has assigned same linear
> address for multiple instances it will not work. If I use this linear
> address for descriptor inside win32 app it will point probably to
> somewhere else. Maybe it would work under w9x.
> Anyway I need to exchange some pointer to data which will work for both
> djgpp prog and win 32 app. As I understand calling VDD allows me to
> exchange data in registers (so maybe pointers) but how to get pointer
> usable for both sides? Or does NT kernel have some special functions to
> read memory inside NTVDM DPMI space? I would imagine somethinkg like
> ntvdm_movedata(UINT32 ntvdm_linear_address, UINT8 *buffer, UINT32 size);

You must distinguish between the VDD and other Win32 applications. The VDD is loaded in the very same process as NTVDM.EXE, that is, it can access the full DOS memory and a valid address in DOS is also valid for the VDD.

OTOH, other Win32 applications run in their own address space. If you need to communicate with them, you can use the normal Win32 process communication methods.

---
MS-DOS forever!

> You must distinguish between the VDD and other Win32 applications. The VDD
> is loaded in the very same process as NTVDM.EXE, that is, it can access the
> full DOS memory and a valid address in DOS is also valid for the VDD.

Aha, understand. So I need to make VDD first (and probably last). You say it can access DOS memory in NTVDM and how about DPMI memory? As I understad you said there's some hack how to access also the DPMI memory. I downloaded hxdpmi but the asm is not very readable for me. I'd like to do all things in (gc)c - it shouldn't be problem.

---
DOS gives me freedom to unlimited HW access.

> > You must distinguish between the VDD and other Win32 applications. The
> VDD
> > is loaded in the very same process as NTVDM.EXE, that is, it can access
> the
> > full DOS memory and a valid address in DOS is also valid for the VDD.
>
> Aha, understand. So I need to make VDD first (and probably last). You say
> it can access DOS memory in NTVDM and how about DPMI memory? As I
> understad you said there's some hack how to access also the DPMI memory. I
> downloaded hxdpmi but the asm is not very readable for me. I'd like to do
> all things in (gc)c - it shouldn't be problem.

the hack is for the "RegisterModule" call, because it uses some pointers which must fit into DS:SI and ES:DI - which might be a problem if your DOS app is 32bit and running in flat protected-mode.

Accessing DPMI memory is no problem at all, since such memory is a simple Win32 virtual memory block. Usually, inside the VDD, if you got addresses from the DOS app, you will translate them by a call of VdmMapFlat() - this call translates SEGMENT:OFFSET or SELECTOR:OFFSET into FLAT. Additionally, you can always inquire the VM's current state with function getMSW() - bit 0 will tell if it is in "real-mode" or protected-mode.

---
MS-DOS forever!

> Look here: http://www.ragestorm.net/tutorial?id=27
> and here: http://www.ragestorm.net/sample?id=94

I'm trying to compile this example under MinGW gcc 3.4.5 by:
gcc -Wall -c GALAXY.C
gcc -shared -o GALAXY.DLL GALAXY.C
It compiles OK without any warning but the DLL doesn't work.
When call bop.com from command line I got only '!' char on console like error that dll was not initialized or missing. No window pop-up :(
With original DLL from MSVC it works. Any idea? Did I forget some special linker arg for a vdd dll?

---
DOS gives me freedom to unlimited HW access.

Aha mingw put some garbage prefix and suffix to DLL export names, so bop.com couldn't find functions InitProc and MyRoutine. Instead there was _Z8InitProcv and _Z9MyRoutinev. Hope gcc have some parameter to avoid this.

EDIT: WTF I found it depends on how do I type galaxy.c if it is uppercase then I got prefixes in DLL. If the filename is lowercase then I got without prefix.
Well it work now! But not very good.
Every even call of bop.com I got this error message.

This don't happen wirh MSVC DLL. But if I UPX this mingw dll then it work without error, how can upx cured it?

---
DOS gives me freedom to unlimited HW access.

> Rayer asked on DJGPP forum whether is possible to allocate buffer in size
> of few MB and shared it between DOS and WinXP applications.
>
> I know know but I've found a trick how to call Windows functions from DOS
> programs. (Windows must be running, of course)
> Look here: http://www.ragestorm.net/tutorial?id=27
> and here: http://www.ragestorm.net/sample?id=94
>
> Another example is sound library for QBasic called DS4QB2
> http://www.qbcafe.net/qbc/english/download/qbasic_library/sound_music.shtml

HA!

One of the most interesting posts/threads I've ever read!!!

Seems like there's finally a solution to some/most of my
DPMI32 <-> WIN NT+ problems...

Thanks a lot to you and the other posters,
Stefan / AH

> Usually, inside the VDD, if you got addresses
> from the DOS app, you will translate them by a call of VdmMapFlat() - this
> call translates SEGMENT:OFFSET or SELECTOR:OFFSET into FLAT.

If I would forward SELECTOR:OFFSET to VDD how it can translate it? It should neeed to look-up to LDT od my DJGPP program first for base of the selector's descriptor - do it automatically?

Unforetunatelly I'm stucked with compiling vdd sample code in mingw and don't have much free time to messing with it now.

And please, do you have a complette prototype of VdmMapFlat?
PVOID VdmMapFlat(IN WORD Segment, IN ULONG Offset, IN VDM_MODE Mode);

What type is VDM_MODE and what is VDM_PM, VDM_V86 valuses? I cannot find it in any .h either on google.

And the VdmMapFlat() can be called only after registering vdd? If I tried to call it in stand-alone exe it returns A0000 for A000,0,0 input instead null.

---
DOS gives me freedom to unlimited HW access.

> > Usually, inside the VDD, if you got addresses
> > from the DOS app, you will translate them by a call of VdmMapFlat() -
> this
> > call translates SEGMENT:OFFSET or SELECTOR:OFFSET into FLAT.
>
> If I would forward SELECTOR:OFFSET to VDD how it can translate it? It
> should neeed to look-up to LDT od my DJGPP program first for base of the
> selector's descriptor - do it automatically?

Yes, of course. The LDT is not a part of your program.

> Unforetunatelly I'm stucked with compiling vdd sample code in mingw and
> don't have much free time to messing with it now.
>
> And please, do you have a complette prototype of VdmMapFlat?
> PVOID VdmMapFlat(IN WORD Segment, IN ULONG Offset, IN VDM_MODE Mode);
>
> What type is VDM_MODE and what is VDM_PM, VDM_V86 valuses? I cannot find
> it in any .h either on google.

the VDM stuff is included in Win2k/WinXP ddk, there's a help file, include files (vddsvc.h, nt_vdd.h, isvbop.h) and an import lib (ntvdm.lib).

> And the VdmMapFlat() can be called only after registering vdd? If I tried
> to call it in stand-alone exe it returns A0000 for A000,0,0 input instead
> null.

Looks ok to me. A000,0,0 means segment=A000, offset=0, pmode=FALSE, that should return linear address A0000.

---
MS-DOS forever!

> Yes, of course. The LDT is not a part of your program.

It's not, its pointed from GDT. But it's created by my program not the OS or is it DPMI call?

> the VDM stuff is included in Win2k/WinXP ddk, there's a help file, include
> files (vddsvc.h, nt_vdd.h, isvbop.h) and an import lib (ntvdm.lib).

OK I got it (250 MB ISO for a few .h files muhehe, but contains also some vdd examples). MinGW has some DDK headers but not complette.

But I'm still not sure about the prototype. VDM_MODE is defined as enum but what is the size of enum? As I looked for it's not a standard but dependent on compiler. Some uses 32bit int, some uses smallest possible type. But I need to know real size which ntvdm.exe takes to make proper import of this function.

---
DOS gives me freedom to unlimited HW access.

> > Yes, of course. The LDT is not a part of your program.
>
> It's not, its pointed from GDT. But it's created by my program not the OS
> or is it DPMI call?

In case you asked whether the LDT is accessed with DPMI calls only then the answer is yes, in NTVDM there's no other possibility.

> But I'm still not sure about the prototype. VDM_MODE is defined as enum
> but what is the size of enum? As I looked for it's not a standard but
> dependent on compiler. Some uses 32bit int, some uses smallest possible
> type. But I need to know real size which ntvdm.exe takes to make proper
> import of this function.

A 32bit C compiler "should" always extend arguments with a magnitude < 32 bit (char, short, word, ...) to a dword, so this is no problem at all.

---
MS-DOS forever!

> A 32bit C compiler "should" always extend arguments with a magnitude < 32
> bit (char, short, word, ...) to a dword, so this is no problem at all.

Yes but there's "should" not "is" or "must". Important is how the ntvdm.exe is compiled. I expect they used MSVC which should use 32bit int.

Here's interesting discussion about this theme:
http://www.gamedev.net/community/forums/topic.asp?topic_id=365184

One post says:

C enums are int-sized. C++ enums are of the smallest size that can represent all the values the enum can take.


---
DOS gives me freedom to unlimited HW access.

> > A 32bit C compiler "should" always extend arguments with a magnitude <
> 32
> > bit (char, short, word, ...) to a dword, so this is no problem at all.
>
> Yes but there's "should" not "is" or "must". Important is how the
> ntvdm.exe is compiled. I expect they used MSVC which should use 32bit
> int.

FYI:

// says "4" for either C or C++ (using DJGPP's GCC 4.2.3)

#include <stdio.h>

enum me { NO,YES } whatever;

int main()
{
  printf("\nsizeof(enum) = %d\n",sizeof(whatever));

  return 0;
}

> // says "4" for either C or C++ (using DJGPP's GCC 4.2.3)

Yes but for me is important if it is true in case of compiler used for ntvdm.exe. I guess MS used theirs MSVC but not sure, even I don't know if it compiled c or c++ code. I want to be sure using right prototype.

---
DOS gives me freedom to unlimited HW access.

> > // says "4" for either C or C++ (using DJGPP's GCC 4.2.3)
>
> Yes but for me is important if it is true in case of compiler used for
> ntvdm.exe. I guess MS used theirs MSVC but not sure, even I don't know if
> it compiled c or c++ code. I want to be sure using right prototype.

The rumor is that MS uses MSVC (various versions) for everything, and that it's mostly C++.

> The rumor is that MS uses MSVC (various versions) for everything, and that
> it's mostly C++.

And is there a way to identify compiler and ++ code from binary image?

---
DOS gives me freedom to unlimited HW access.

> > The rumor is that MS uses MSVC (various versions) for everything, and
> that
> > it's mostly C++.
>
> And is there a way to identify compiler and ++ code from binary image?

Not sure in there is a working example that actually does this for what you want. But you can always try PHaX's GetTyp/GT2 and/or Veit K.'s Typ and/or Marco's TrID.

> > Do you have some short PM call example, please?
>
> Sorry, there are no samples and no tutorials. But it's done in the
> following apps, available with source on japheth.de:
>
> - FD Debug (Nasm)
> - hxntvdm (Masm)
> - idecheck (Masm)

Also don't forget things like NTOLDAPP and NTLFN:

http://gd.tuwien.ac.at/pc/dos/djgpp/current/v2misc/ntlfn08b.zip
http://gd.tuwien.ac.at/pc/dos/djgpp/current/v2misc/ntlfn08s.zip

http://www.phatcode.net/downloads.php?id=188

> Not sure in there is a working example that actually does this for what
> you want. But you can always try PHaX's
> GetTyp/GT2 and/or Veit
> K.'s Typ and/or
> Marco's TrID.

Thx, I tried this programs and found ntvdm was made by Linker 7.10 VC++ probably 2003... but still not sure if it is C or C++ code.

---
DOS gives me freedom to unlimited HW access.

> Thx, I tried this programs and found ntvdm was made by Linker 7.10 VC++
> probably 2003... but still not sure if it is C or C++ code.

ntvdm    exe       420,864            Apr,13,2008   07:12:30pm   A...

Does that look bloated enough to be written in C++? I think not.

EDIT: Okay, seriously, just open it up with a hex editor, and you can see obvious things like this:

d:\xpsp\base\mvdm\softpc.new\host\src\nt_timer.c
d:\xpsp\base\mvdm\softpc.new\host\src\nt_eoi.c
d:\xpsp\base\mvdm\softpc.new\host\src\nt_com.c
d:\xpsp\base\mvdm\softpc.new\host\src\config.c
d:\xpsp\base\mvdm\softpc.new\host\src\nt_fulsc.c