Mail Archives: djgpp/2012/05/21/20:15:08
Hi,
On May 21, 3:57 am, RayeR <gl DOT DOT DOT AT centrum DOT cz> wrote:
>
> Just a note, if you want to use >4GB RAM in windows the 64bits is not
> only one possible way. I guess you heard about PAE. It's supported in
> server editions of win2000 and win2003 and also vista and 7.
I don't think this is well-supported, if at all, and not for home
editions, at least, due to "driver bugs". Also, Geoff Chappell pretty
much proved that it is due moreso to licensing restrictions. Hence,
while you could do it in 32-bits, it seems MS doesn't prefer that.
> Also it
> works well in Linux (may require that you will recompile kernel with
> enabled PAE feature).
Right, but some drivers probably won't work. Besides, Windows doesn't
have all sources to all existing drivers, so it's harder for them.
> Your windows apps will not be able to use >4GB
> at once but more runnings apps can utilize >4GB from system. If you
> have 32bit version of Vista or 7 you can try this patchhttp://arstechnica.com/civis/viewtopic.php?f=15&t=49358
> that will cure the windows kernel to not be limited by nonsense
> restrictions.
As mentioned, it's not really supported, esp. due to arbitrary
licensing and MS bias (apparently) in favor of Win64. Not all editions
let you use any available gigs of RAM.
> But you may expect that some driver will not be PAE
> compatible and cause crash at boot and you will have to revert and
> track the problem.
Which makes it fairly useless, sadly. :-(
> But it's a way to go. My way is to stay on XP-SP3
> until there will be drivers for new hardware. I know it will not last
> forever.
XP is already "deprecated" by MS. I hold no hopes to that. Of course,
MS has other fish to fry which kinda clouds their judgment, IMO.
> Then I probably switch fully to Linux with use of wine,
> dosemu/dosbox, vmware etc.
WINE isn't perfect by any stretch. I like DOSBox and DOSEMU and
VirtualBox too, but all of them have tradeoffs, bugs, limitations. But
yeah, Linux with all those tools does work better than "modern"
Windows, at least for DJGPP.
> About DOS 32bit bins support under Win64 - On bttr forum it was
> noticed that openwatcom can do this. It can make standard win32 PE
> console apps that are stubbed to run under DOS. So they runs under
> Win64 too because stub is not executed instead PE is loaded.
It doesn't need to modify anything. A vanilla OW-produced PE .EXE will
(hopefully) run under HX emulation DLLs. But that depends on what API
calls it makes, etc. Of course HX doesn't support quite everything
through XP. But it's quite a large subset.
wcl386 hello.c /bcl=nt
dpmild32 hello.exe
REM or load HXLDR32.COM TSR then run "hello" at your leisure
REM though you can also stub in DPMIST32.BIN in the
REM DOS MZ (sub)header if desired
> I think
> this is possible way for DJGPP - it could exploit openwatcom's libc
It's not really OW's Win32 libc that supports DOS, only that HX DLLs
(mostly) fake it for us.
> and support of PE format, we already have HDPMI for running win32
> PEs...
And we already have DJELF for (allegedly) running Linux ELF .so files
verbatim.
> But my knowledges don't go so deep here to write it all myself.
> I rather wrote some thin layer and driver that let me use source
> compatibility and compile separately under dos/linux/win32 (all gcc)
> same source.
You basically want to use GCC instead of OpenWatcom, but DJGPP is tied
to its own libc, same as OW is tied to various things. I don't know
how practical it is to merge them (though for sure adding extra POSIX
stuff to OW libc wouldn't hurt).
- Raw text -