tags:

views:

110

answers:

4

Any minimal example of 16bit .com display a window GUI using Win32 API on Windows?

A: 

Are you looking for something along these lines? http://support.microsoft.com/kb/154093

PieterG
Yeah, but wouldn't it have to be a 16-bit Windows executable calling the thunks? I get the impression from the question that it's a DOS .COM file, which doesn't normally interoperate well with the Windows APIs, either 16- or 32-bit.
ChrisV
+4  A: 

The Multiplex Interrupt (interrupt 0x2f) can be used to access various Windows functionalities from a DOS session within Windows, but it only gives access to a select number of capabilities; there's no way to use an arbitrary API call via it as far as I know.

Ignacio Vazquez-Abrams
+6  A: 

Win16 -> Win32

This can be done using CallProc32W

* Call LoadLibraryEx32W() to load the Win32 DLL.
* Call GetProcAddress32W() to get the address of the DLL routine.
* Call the DLL routine using CallProc32W() or CallProcEx32W. 

Code Example

Conzept

Dos -> Win32

http://www.ragestorm.net/tutorial?id=27

stacker
But doesn't that only work for NE executables?
SamB
+1  A: 

That won't work. Assuming your goal is to make a program that can run either in plain DOS or in Windows, you have a couple of options:

The easiest option would be to use the DOS extender HX, which allows you to run applications using a large subset of the Win32 API under DOS. Basically, you would just create a win32 app as usual, then run the PEstub tool on the executable to allow it to run under DOS. PEstub works by replacing the DOS stub with one that invokes HX to load and run your win32 program. There are two drawbacks to this approach:

  1. It only works with a 386 or higher CPU, since you can't exactly run a win32 program without one.

  2. You would have to distribute several additional files; at bare minimum:

    • DPMILD32.EXE - PE binary Loader (automatically invoked by the DOS stub on your EXE)

    • DKRNL32.DLL - emulates KERNEL32.DLL

    • DUSER32.DLL - emulates USER32.DLL

    If you can't count on a DPMI server being active already (or don't know what that means), you'd better also include:

    • HDPMI.EXE - DPMI Server (automatically loaded by DPMILD32 if no server was loaded yet)

The DOS stub in a win32 executable is the part that typically prints out a message along the lines of "Haha, sucker, you can't run this program in your puny DOS! Try Windows 95 instead!" when your run a windows program in DOS. It doesn't have to do that, though; it could be any MZ-format MS-DOS executable you like: I've seen self-extracting zip archives that used this to allow extraction on DOS, but present a GUI on win32 systems.

This leads us to the other option: you could write both the win32 application and its DOS stub yourself, and instruct the linker to use your stub instead of the default one. For example, if you use MSVC to build your win32 app, you would use link.exe's /STUB option. I'll assume you can figure out how to produce the MS-DOS .exe to pass to the linker on your own. This approach also has two big disadvantages:

  1. You essentially have to write two different programs, though with care they could share source files.

  2. You need to produce an MS-DOS executable, which means that you either need to use a tool that can create them, or at least add some messy boilerplate to your assembler code.

SamB