compiler error on Windows 2003
Tomasz Zbrożek
(and also on real MS-DOS with cwsdpmi) it compiles ok, but on 2003, while
compiling one of the source files I get:
cc1plus.exe: out of memory allocating 65536 bytes after a total of 23875360
bytes
I suppose it's because of different DPMI on XP and 2003.
Do you know what is the reason of this error and how to solve the problem ?
Or where can I read something on this ? I can't find any information about
such problem.
regards,
tomek
Rugxulo
Assuming you have all the MS updates (e.g. SP2), it's probably fixed
just like Vista by setting the following registry entry:
HKLM\System\CurrentControlSet\Control\Wow\DpmiLimit
(REG_DWORD) is the value of memory you want in bytes. Any value less
than 32 MB will be raised to 32 MB.
Otherwise, if that doesn't work, you'll have to use NTDPMIX (put
the .DLL in %WINDIR%\SYSTEM32 and run the .EXE from CLI when needed):
http://www.japheth.de/Download/NTDPMIX.zip (w/ srcs)
Or just lower your optimization level to -O and use -Wl,--reduce-
memory-overheads ... or run under QEMU or dual boot FreeDOS or try
DOSEMU under Linux (but edit .dosemurc first!) or try DOSBox (edit
dosbox.conf!) or build a Cygwin-hosted cross compiler or try OS/2 (or
buy eCS) or use an old Win9x machine or e-mail it to me and I'll
compile it or .... (Did I leave any stone unturned? lol) :-)
Tomasz Zbrożek
thanks a lot for your explanation! 2003 we use is fully updated, we tried
DpmiLimit, ntdpmix -m 128 (but ntdpmix is for WinXP not 2003), also we
tried to use HKLM\Syste\CurrentControlSet\Control\Wow\ settings from XP
(wowsize etc.) but allocator test program (vista1.exe) still can't allocate
more than 32 MB on Windows 2003! :(
I'm interested in cross compiler for Cygwin ! Can I find compiled one
somewhere ? or some script to use for compile it from sources ?
As you surely know DOSBox (0.72) is very slow for compilation purposes, I
tried to reconfigure dosbox.conf but it doesn't seem dosbox works faster.
best regards
tomek
Robert Riebisch
> Hi, I have problem with compiling my application on Windows 2003, on XP
> (and also on real MS-DOS with cwsdpmi) it compiles ok, but on 2003, while
> compiling one of the source files I get:
Please reveal more details about your DJGPP setup. Which packages are
you using?
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
Rugxulo
On Apr 3, 4:45 am, "Tomasz Zbro¿ek" <t.zbro...@upos.com.pl> wrote:
>
> Rugxulo,
> thanks a lot for your explanation! 2003 we use is fully updated, we tried
> DpmiLimit, ntdpmix -m 128 (but ntdpmix is for WinXP not 2003),
NTDPMIX works on Vista too, just that Japheth I guess never officially
intended it except as a way to improve XP's default DPMI host.
> also we
> tried to use HKLM\Syste\CurrentControlSet\Control\Wow\ settings from XP
> (wowsize etc.) but allocator test program (vista1.exe) still can't allocate
> more than 32 MB on Windows 2003! :(
I guess you mean "System" not "Syste". Also you may have to reboot for
it to take effect. Also, HKLM should really probably be
HKEY_LOCAL_MACHINE (or whatever) which already exists, but I
personally had to add the "DpmiLimit" entry manually (via REGEDIT).
I've been told this doesn't work in Vista Home Basic pre-SP1 either,
hence the NTDPMIX suggestion.
Assuming you did everything correctly, I don't know what to tell
you! :-( I seriously thought it would work since Vista and 2k3
(esp. with service packs) are so closely related.
> I'm interested in cross compiler for Cygwin ! Can I find compiled one
> somewhere ? or some script to use for compile it from sources ?
I wish. I'm sure someone has done it, but I never managed. Maybe
someone here has one (although I suspect that it's not too too common
because DJGPP usually runs fine, at least on 32-bit Windows). When
x86-64 becomes common place, I will definitely want such a cross
compiler.
> As you surely know DOSBox (0.72) is very slow for compilation purposes, I
> tried to reconfigure dosbox.conf but it doesn't seem dosbox works faster.
Well, more specifically I meant tweak "memsize" to be "64" (since 64
MB RAM is the max.) instead of default 16. Yes, it's extremely slow,
approx. 486 speeds for me. Also, as others have correctly mentioned,
it's not always wise to trust an emulator to compile your sources
(since a real machine is obviously less buggy).
You could also try temporarily downgrading to G++ 3.4.4 to compile
your stuff, which uses lots less memory than the latest 4.3.2. (I
remember I had to do that to compile Dungeon Crawl 4.0.0.b26 with -O2
before I knew about the Vista fix.) Also, do try with lower (or no!)
optimizations (e.g. -O0) for the one bit that won't compile otherwise
(and do use "-Wl,--reduce-memory-overheads" if you use BinUtils 2.17
or newer).
P.S. Not really recommended, but you *could* try RSXNT with DJGPP if
you really wanted. But it's probably easier (less abandoned) to just
use Cygwin or OpenWatcom, IMHO.
Tomasz Zbrożek
> Please reveal more details about your DJGPP setup. Which packages are
> you using?
>
We use DJGPP v2.04 (I know it's beta but we need DXE3 feature!), with
gcc/gpp 4.3.2 and gcc/gpp 3.4.4 (I noticed it's faster than 4.3.2). Also we
use DXE 3.11 from http://www.geocities.com/dborca/.
PS. I say "we" in my mails becasue I write as a memer of a team at my work
place, and I/we are working on porting application we maintain from Borland
DPMI16 to DJGPP! I can say it generally works now but of course we still
have some job to do and some problems to solve :)
Tomasz Zbrożek
> You could also try temporarily downgrading to G++ 3.4.4 to compile
> your stuff, which uses lots less memory than the latest 4.3.2.
I tried with 3.4.4 and result is much better but on compiling biggest *.cpp
file of the project gpp failed with out of memory. Maybe on monday we will
try to divide this file to smaller parts :) I tried with -O0 option (-Wl,--
reduce-memory-overheads was not needed yet because it did not reach linking
phase).
Rugxulo
On Apr 3, 8:51 am, "Tomasz Zbro¿ek" <t.zbro...@upos.com.pl> wrote:
> Rugxulo <rugx...@gmail.com> wrote in
Try -Wa,--reduce-memory-overheads (for GAS, although I doubt that will
help much). Also try not using "-Wall" and see if that lowers memory
any. Don't forget that 3.4.4 G++ is object incompatible with 4.3.2,
though. As for why it needs so much RAM, I guess the blame goes to
templates, genericity, or whatnot. Heck, you could even try 3.3.6 or
3.2.3 if necessary. Or Maybe try once with "gcc -v" and then manually
do what it does (without using the gcc driver) to decrease its
footprint a little.
EDIT: Ah, I forgot about this, maybe this will help most of all
(although I'm not sure those values are truly optimal, I think 0 and
4096 will work even better but much slower)?
--param ggc-min-expand=10 --param ggc-min-heapsize=8192
N.B. You may have to use a response file if it surpasses 126 bytes
cmdline length: gcc @my_options.txt myfile.cpp
Tomasz Zbrożek
> EDIT: Ah, I forgot about this, maybe this will help most of all
> (although I'm not sure those values are truly optimal, I think 0 and
> 4096 will work even better but much slower)?
>
> --param ggc-min-expand=10 --param ggc-min-heapsize=8192
>
hi,
I used these two parameters (10 and 8192 values) with gpp 3.4.4 and finally
I compiled and linked our application on Windows 2003. Anyway another
problem is to debug it on Win2003 :))) and I think it won't be possible
with 32MB RAM restriction... our application exe file with debug
information has 19 MB size, RHide crashes with "divide by zero" error when
I load project file (on XP when project file is loaded ntvdm process takes
49 MB) and RHGDB quits with no information when I run the application (on
XP ntvdm process takes 29 MB when application is being run and stopped on
the first breakpoint)... of course on the XP there is no problem to debug
this application with RHide (the newest I know is 1.5c with gdb 6.3) or
RHGDB.
Again, thank you very much for help Rugxulo!
Rugxulo
On Apr 6, 4:55 am, "Tomasz Zbro¿ek" <t.zbro...@upos.com.pl> wrote:
> Rugxulo <rugx...@gmail.com> wrote in
>
> > EDIT: Ah, I forgot about this, maybe this will help most of all
> > (although I'm not sure those values are truly optimal, I think 0 and
> > 4096 will work even better but much slower)?
>
> > --param ggc-min-expand=10 --param ggc-min-heapsize=8192
>
> hi,
> I used these two parameters (10 and 8192 values) with gpp 3.4.4 and finally
> I compiled and linked our application on Windows 2003.
Good! DJGPP gets a reprieve from the governor! (Who needs a bugfix
when you can have a workaround?) ;-)
> Anyway another
> problem is to debug it on Win2003 :))) and I think it won't be possible
> with 32MB RAM restriction... our application exe file with debug
> information has 19 MB size,
I've been told that debugging info isn't loaded in normal execution.
> RHide crashes with "divide by zero" error when
> I load project file (on XP when project file is loaded ntvdm process takes
> 49 MB) and RHGDB quits with no information when I run the application (on
> XP ntvdm process takes 29 MB when application is being run and stopped on
> the first breakpoint)... of course on the XP there is no problem to debug
> this application with RHide (the newest I know is 1.5c with gdb 6.3) or
> RHGDB.
>
> Again, thank you very much for help Rugxulo!
I'm not done yet! :-)
You can always use DOSEMU (which has static compiles of it plus
FreeDOS on its SourceForge page). It works quite well in my limited
testing (although I didn't try debugging anything). Of course, it
comes with default 20 MB DPMI limit, but that can be configured
(.dosemurc or "dpmi -m 0xA000" will double it, for instance). I tried
DOSEMU the other day in CDlinux, and it ran quite well (GdM's 3d
engine, Tran's Timeless demo, compiling stuff via DJGPP). Honestly
though, CDlinux comes with DOSBox and WINE but not DOSEMU by default
(which is weird since DOSEMU is much faster and quite good). But two
simple .tar.gz files from the homepage aren't exactly a huge download,
so it's easy to install.
Also, dare I suggest, but maybe you can use OpenWatcom if your app
isn't too DJGPP or GCC specific. It at least supports various non-DOS
hosts, including Windows, which can cross-compile for DOS. That won't
let you debug, but it might prove useful as an alternative.
P.S. Just to be exhaustive for future reference (and you'll have to
ask DJ or Eli or CWS for more details), I think you can decrease the
transfer buffer and/or default stack size (via stubedit) to save even
more memory still albeit not as much as the garbage collection --param
values mentioned above.
Tomasz Zbrożek
>
> Also, dare I suggest, but maybe you can use OpenWatcom if your app
> isn't too DJGPP or GCC specific. It at least supports various non-DOS
> hosts, including Windows, which can cross-compile for DOS. That won't
> let you debug, but it might prove useful as an alternative.
Does OpenWatcom have DLL feature ? What I read is that there is no
official DLL support for DOS... I afraid that it's not so easy to learn how
to use it :) It was hard enough for me to make my program work with DXE and
finally DXE3 :) eh!
Rugxulo
On Apr 7, 4:48 am, "Tomasz Zbro¿ek" <t.zbro...@upos.com.pl> wrote:
> Rugxulo <rugx...@gmail.com> wrote in
At the risk of prying you away from the best DOS compiler in the world
(DJGPP) ...
Yes, Causeway supports .DLLs in DOS. And most Win32 .EXEs (PE)
produced by OpenWatcom can run under HXRT in pure DOS, even
with .DLLs. For instance, here's quoting from BINW's WLSYSTEM.LNK:
system begin cwdlls
option osname='CauseWay DLL (Stack parameter passing)'
libpath %WATCOM%/lib386
libpath %WATCOM%/lib386/dos
op stub=cwdstub.exe
format os2 le dll ^
libfile dllstrts.obj
end
system begin cwdllr
option osname='CauseWay DLL (Register parameter passing)'
libpath %WATCOM%/lib386
libpath %WATCOM%/lib386/dos
op stub=cwdstub.exe
format os2 le dll ^
libfile dllstrtr.obj
end
Keep in mind that I only suggest this since you're having such trouble
with Windows. Otherwise, DJGPP would be quite good enough (and has
better C++ support although OW18 has improved a lot). If I had a
Cygwin cross compiler for you, but alas ....
P.S. I think you have to use VDMSERV.EXE to debug DOS apps on Windows,
and even then, I'm fairly certain graphical stuff won't work. You'll
get more help for this on the following newsgroups:
http://groups.google.com/group/openwatcom.users.c_cpp/topics
http://groups.google.com/group/openwatcom.contributors/topics
And here's a link to HXRT:
Rod Pemberton
news:27613ce0-24ef-4e1b...@y7g2000yqa.googlegroups.com...
> And most Win32 .EXEs (PE)
> produced by OpenWatcom can run under HXRT in pure DOS, even
> with .DLLs.
OH! Thanks for the reminder. My old PC wasn't "enough" of "whatever"
(memory, speed, etc.) to run applications with HX well. This one should be.
IIRC, I couldn't get QEMU to run, although I do recall some game running -
probably with DOSBOX.
Rod Pemberton
Tomasz Zbro�ek
> At the risk of prying you away from the best DOS compiler in the world
> (DJGPP) ...
>
I prefer GNU software :) but I like to know all the possibilities so I will
read a bit about Open Watcom in spare time, because I do not know its
features.
Right now we are porting our application (+ its dlls) to DJGPP !
Our destination is also GNU/Linux port so DJGPP, except for all the well
known advantages, is also good stage on a way to Linux :)
Rugxulo
On Apr 8, 3:07 am, "Tomasz Zbro ek" <t.zbro...@upos.com.pl> wrote:
> Rugxulo <rugx...@gmail.com> wrote in
>
> > At the risk of prying you away from the best DOS compiler in the world
> > (DJGPP) ...
>
> I prefer GNU software :) but I like to know all the possibilities so I will
> read a bit about Open Watcom in spare time, because I do not know its
> features.
There's GNU compilers for Windows, e.g. MinGW (uses MSVCRT.DLL) and
Cygwin (uses CYGWIN1.DLL). If you want it to run fast, choose MinGW.
If you want POSIX and don't mind using GPL (or similar "free software"
license), choose Cygwin. OpenWatcom requires none of those .DLLs. Nor
does DJGPP, and it's the latest GCC (well, almost ... get 4.3.3 pre-
release from Andris' page if you're really desperate). All of the
above have full sources available. The problem is that 16-bit stuff
(like OW also supports) as well as the internals of DJGPP are not in
vogue anymore, so people have deprecated them like the plague. This is
the only "real" reason DOS stuff doesn't work as well on 2k3, Vista,
etc. For x86-64, for unknown reasons (patents?), AMD chucked V86 mode,
so that kills 16-bit too (except in slow VMs). It's really sad to me
that everything gets deprecated so quickly in favor of the
"new" (which itself is deprecated before too long). I don't recall
ever talking to any programmer who actually "wanted" to rewrite
everything from scratch every few years.
> Right now we are porting our application (+ its dlls) to DJGPP !
> Our destination is also GNU/Linux port so DJGPP, except for all the well
> known advantages, is also good stage on a way to Linux :)
OpenWatcom even has "experimental" (read: buggy) GNU/Linux support. It
can't hurt to try it, IMHO. They support compiling from any supported
32-bit host OS (for any target) out of the box.