did anybody ever sucessfuly hack the guts of a 32bit win app and get it running in dos 32bit unreal mode just wondring

In the famarm thread rugxulo posted a link to DOS program that can load and run Windows binaries.

http://board.flatassembler.net/topic.php?p=112636#112636

You can get similar functionality to WDOSX with HX DOS Extender and it's Win32 API layer is better. However none of those tools will let you run in FRM/unreal mode but only in protected mode (please note that v86 mode is a form of pmode).

There is basically no reason to run Win32 API under FRM/unreal mode since it does not provide control over memory allocation and privileges. According to definition in FRM mode 64kb code segment limit still applies although it is possible to overcome this and switch from 16/32 bit code. You would also need to setup certain memory structures and segment registers which could be hard (if not impossible) using plain FRM/unreal mode. Without proper memory management in place most application would eventually fail and crash probably.

You could try to get away with some old 16bit Windows API but I still see no reason to do it. To make long story short why would anyone run Win32 API application in unreal mode?

thx for the replies
@acp the short long story is i hav some small win32 apps that do things like i want but i dont want to run win os
i dont know a lot about win apps but i ges the botom line is that micro$oft win os forces them all to be as exclusive of other os as posible
i tried dos extenders and stub extractors but they alway seem to fail to set up the enviroment needed for the apps si i just wonderd if anyone knew if the win api stuff could be hacked out and just the 32bit pmode code run outside of win but i ges its too hard but mayb not imposible

You can run them in 32-bit PM using HX. Unreal mode doesn't have paging, and Win32 apps do need it (maybe not absolutely ...).

http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.HXDOScomplists

Congrats on copying my answer

Basically the best results are with Windows console applications. Besides HX and WDOSX you can also try PharLap TNT (8.0 is the latest version if I remember correctly) but I'd be very surprised if your application would not work under HX but actually worked under TNT Dos Extender.

Secondly you don't need stub extractor, you rather need some tool to add proper stub to your executable or run your Win32 app using the extender main executable and passing your app name as a command line argument.

The objective of stub is to either include dos extender or run it from external binaries before running your app code. Stub extractors are removing stub part from your binary so this is not an option you are looking for. Stub code is part of DOS EXE MZ file type, usually after the stub there is LE/LX/NE/PE header for Windows application or Dos Extender application.

Some extenders during adding stub allows to enable compression/encryption - I would advice to turn those options off.

There is nothing magical nor Microsoft did any special tricks to prevent MS Windows apps running under other environments, especially ones that are not multitasking and without memory protection like DOS providing less then 10% of functionality being required to load and run application.

You can't run Linux apps under DOS nor Windows directly even thou everything is open source. It's not the fault of any operating system. The differences in ABI and API (plus executable file format differences) prevent running applications compiled for one OS on completely different systems. Some systems like *BSD provide almost out-of-the box emulation of Linux and other *BSD systems which enables to run ELF binaries for the same CPU architecture on single system. And keep in mind that from certain perspective Linux and *BSD systems have some parts quite common.