Can WINE be made for DOS using GCC for DOS?

[Todd S.]

Hello! My name is Todd, and I know this sounds like a stupid question, but if it was ever possible, could the "WINE" application ever be built with the "DOS" version of GCC/G++ so Windows programs can be executed from DOS-mode?

Thanks.

Regards,
Todd Suess

[Erik de Castro Lopo]

On Sat, 4 Sep 2004 20:26:02 -0400
"Todd S."  wrote:
> Hello! My name is Todd, and I know this sounds like a stupid question,
> but if it was ever possible, could the "WINE" application ever be
> built with the "DOS" version of GCC/G++ so Windows programs can be
> executed from DOS-mode?

No wine needs to run on top of a modern multitasking POSIX like
operatinging system. To do that on top of DOS would mean that
you basically need to replicate at least 50% of the features 
of Linux before you could run Wine.

Erik

[Steven Edwards]

Hi Todd,

--- "Todd S."  wrote:
> Hello! My name is Todd, and I know this sounds like a stupid
> question, but if it was ever possible, could the "WINE" application
> ever be built with the "DOS" version of GCC/G++ so Windows programs
> can be executed from DOS-mode?

There are quite a few problems with this and I dont even know all the
issues but I will give you a list of what I do know.

1. Dos is of course 16 bit so you would need to do something along the
lines of djgpp or a 32bit dos extension and memory management.

(I have given some thought to attempting to build the Win16 support in
Wine in djgpp so we could attempt to build a Win16 VDM for ReactOS)

2. Wine assumes a lot of Unixisms for the Wineserver. In short you
could port the Win32api to almost anything but you still need a way to
load the programs and emulate the enviorment. This means you need a PE
loader as DOS programs are MZ.

3. You would still need a working GDI/User driver for the dos
framebuffer. Well you would need a whole Graphics subsystem.

Why are you interested in this? Are you wanting to support Windows
applications on FreeDOS? One project that I know of tried to go down
this route and it is quite a dead route. I would recommend working with
ReactOS instead if that is your goal.

Thanks
Steven

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

On Sat, Sep 04, 2004 at 08:26:02PM -0400, Todd S. wrote:
> Hello! My name is Todd, and I know this sounds like a stupid question, but if it was ever possible, could the "WINE" application ever be built with the "DOS" version of GCC/G++

Why use a DOS GCC/g++? Would such a thing exist?  I'd presume you'd use
a commercial, expensive, C compiler on DOS... I'm not sure building WINE
under a C dos compiler is the issue.  The issue is running it.  DOS is
16-bit.  Linux and Windows are 32-bit.  Except for the 64-bit versions
of said OSes.
> so Windows programs can be executed from DOS-mode?

I have no such experience, but I would EXTREMELY SEVERELY doubt this.

DOS is a console mode OS, and Wine runs on X11/Linux, which is a
graphical interface on a generic OS base.  Without a X server or
equivilant, you can't do this, and if you did have an X server, this
would be very pointless.

Furthermore, the same limitation that causes 80% (estimate) of Windows
apps in console mode not to work under DOS is that DOS is 16-bit, not
32-bit, and as such, uses 16 bit integers in it's C compiling.  That
would be a big issue.  You would be wanting something that allows you to
run 32-bit console apps on DOS console, a completely different utility.
(Wineconsole doesn't run on a standard terminal, IIRC, it runs under an
X display, just like wine.) Of course, you *could* try something like
Wine on X11 on Linux on UMSDOS on a MSDOS filesystem, but that would be
just running linux on top of DOS, as opposed to just running linux from
a native ext2/3 or similar partiton.  (UMSDOS, btw, has huge performance
issues.)

I believe, to achieve your goal, you're looking at taking the source
code of apps, changing the ints and declares and whatnot so that the
program will run under 16-bit, and then recompiling.  But that doesn't
solve the issue of LFN, dlls, APIS, etc. etc. -- you'd probably be
better off just buying Windows, and/or installing Linux properly, and
running your app(s) under X11.

BTW, everyone else on wine-devel, please correct me if I'm wrong.
> Thanks.
>
> Regards,
> Todd Suess

--Michael Chang

[Jeroen Janssen]

Hi,

For those interested, I remember there is this thing called 'wdosx' ( 
http://michael.tippach.bei.t-online.de/wdosx/ ), that is a DOS eXtender 
containing a stubbed subset of the WIN32 API.

From the README.TXT:

"Probably the most advanced feature of WDOSX  is its emulation of a 
subset of the Win32 API, making it work  with compilers that were not 
originally designed to create 32 bit DOS programs.

As of current, the  following Win32 API functions  are emulated by 
WDOSX, either completely, in parts or as stubs:

(Note: This table is a bit out of date and reflects the status of WDOSX
  0.95. I've got more important things to do at the moment.)

Module    Exports

KERNEL32  AllocConsole, AreFileApisANSI, Beep, CloseHandle,
            CompareStringA, CreateConsoleScreenBuffer, CreateDirectoryA,
            CreateDirectoryW, CreateFileA, CreateFileW, CreateProcessA,
            DebugBreak, DeleteCriticalSection, DeleteFileA, DeleteFileW,
            DosDateTimeToFileTime, EnterCriticalSection, EnumCalendarInfoA,
            ExitProcess, FileTimeToDosDateTime, FileTimeToLocalFileTime,
            FileTimeToSystemTime, FillConsoleOutputAttribute,
            FillConsoleOutputCharacterA, FindClose, FindFirstFileA,
            FindNextFileA, FlushConsoleInputBuffer, FlushFileBuffers,
            FormatMessageA, FreeConsole, FreeEnvironmentStringsA,
            FreeEnvironmentStringsW, FreeLibrary, GetACP, GetCPInfo,
            GetCommandLineA, GetConsoleCP, GetConsoleCursorInfo,
            GetConsoleMode, GetConsoleOutputCP, GetConsoleScreenBufferInfo,
            GetCurrentDirectoryA, GetCurrentProcess, GetCurrentThreadId,
            GetCurrentTime, GetDateFormatA, GetDiskFreeSpaceA,
            GetDriveTypeA, GetEnvironmentStrings, GetEnvironmentStringsA,
            GetEnvironmentStringsW, GetEnvironmentVariableA,
            GetExitCodeProcess, GetFileAttributesA, GetFileAttributesW,
            GetFileInformationByHandle, GetFileSize, GetFileTime,
            GetFileType, GetFullPathNameA, GetLargestConsoleWindowSize,
            GetLastError, GetLocalTime, GetLocaleInfoA, GetLogicalDrives,
            GetModuleFileNameA, GetModuleHandleA,
            GetNumberOfConsoleInputEvents, GetNumberOfConsoleMouseButtons,
            GetOEMCP, GetPrivateProfileStringA, GetProcAddress,
            GetStartupInfoA, GetStdHandle, GetStringTypeA, GetStringTypeW,
            GetSystemDefaultLCID, GetSystemInfo, GetSystemTime,
            GetTempFileNameA, GetThreadLocale, GetTickCount,
            GetTimeZoneInformation, GetVersion, GetVersionExA,
            GetVersionExW, GetVolumeInformationA, GlobalAlloc, GlobalFlags,
            GlobalFree, GlobalHandle, GlobalLock, GlobalMemoryStatus,
            GlobalReAlloc, GlobalSize, GlobalUnlock, HeapAlloc, HeapCreate,
            HeapDestroy, HeapFree, HeapReAlloc, HeapSize,
            InitializeCriticalSection, InterlockedDecrement,
            InterlockedExchange, InterlockedIncrement, IsBadCodePtr,
            IsBadHugeReadPtr, IsBadHugeWritePtr, IsBadReadPtr,
            IsBadWritePtr, LCMapStringA, LCMapStringW,
            LeaveCriticalSection, LoadLibraryA, LoadLibraryExA, LocalAlloc,
            LocalFileTimeToFileTime, LocalFree, LocalReAlloc, MoveFileA,
            MultiByteToWideChar, OutputDebugString, PeekConsoleInputA,
            QueryPerformanceCounter, QueryPerformanceFrequency,
            RaiseException, ReadConsoleA, ReadConsoleInputA, ReadFile,
            RemoveDirectoryA, RemoveDirectoryW, RtlUnwind,
            ScrollConsoleScreenBufferA, SetConsoleCtrlHandler,
            SetConsoleCursorInfo, SetConsoleCursorPosition, SetConsoleMode,
            SetConsoleScreenBufferSize, SetConsoleWindowInfo,
            SetCurrentDirectoryA, SetCurrentDirectoryW, SetEndOfFile,
            SetEnvironmentVariableA, SetFileAttributesA,
            SetFileAttributesW, SetFilePointer, SetFileTime,
            SetHandleCount, SetLastError, SetStdHandle,
            SetUnhandledExceptionFilter, Sleep, SystemTimeToFileTime,
            TerminateProcess, TlsAlloc, TlsFree, TlsGetValue, TlsSetValue,
            UnhandledExceptionFilter, VirtualAlloc, VirtualFree,
            VirtualQuery, WaitForSingleObject, WideCharToMultiByte,
            WriteConsoleA, WriteConsoleOutputA, WriteFile,
            WritePrivateProfileStringA, _hread, _hwrite, _lclose, _lcreat,
            _llseek, _lopen, _lread, _lwrite,  lstrcat, lstrcatA, lstrcmp,
            lstrcmpA, lstrcmpi, lstrcmpiA, lstrcpy, lstrcpyA, lstrcpyn,
            lstrcpynA, lstrlen, lstrlenA
  USER32    CharToOemA, CharToOemBuffA, CharToOemW, EnumThreadWindows,
            GetKeyboardType, GetSystemMetrics, IsCharAlphaNumericA,
            LoadStringA, MessageBoxA, MessageBoxExA, OemToCharA,
            OemToCharBuffA, OemToCharW
  OLEAUT32  SysAllocStringLen, SysFreeString, SysStringLen,
            VariantChangeType, VariantChangeTypeEx, VariantClear,
            VariantCopy, VariantCopyInd, VariantInit
  ADVAPI32  RegCloseKey, RegOpenKeyA, RegOpenKeyExA, RegQueryValueExA"

Todd S. wrote:
> Hello! My name is Todd, and I know this sounds like a stupid question, but if it was ever possible, could the "WINE" application ever be built with the "DOS" version of GCC/G++ so Windows programs can be executed from DOS-mode?
>
> Thanks.
>
> Regards,
> Todd Suess