Could 16bit .com executables call win32 APIs?

Question

16bit .com的任何最小示例在Windows上使用Win32 API显示窗口GUI？

Answer 1

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

Concept

Dos -> Win32

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

Answer 2

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.

Answer 3

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.