Paul, Very cool. Thats the best description of the problem that I've read. I read a different one having found it on a google group search that was slightly confusing but was trying to say the same thing. You have just clared up the whole problem defination for me! The change that caused this headache for us involved adding several long named forms and removing a couple of short named forms. :o) It must have flicked us over the 64k limit.
We stopped using a tool that I wrote ages ago to reduce the size of the exe which might do the trick for us. It builds the exe without including the dfms. They are instead bundled into a seperate compressed data file that is shipped with the exe. Whenever a form is created it's resource data is streamed in from this seperate file instead of the exes own resource section as normal. This might get around the problem permanently if we start using it again. Caching this external DFM data in memory means forms are created quicker too. Cheers, Nahum. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, 11 June 2004 16:00 p.m. > To: [EMAIL PROTECTED]; NZ Borland Developers Group - > Delphi List > Subject: RE: [DUG] Windows 98 problems > > > Hi, Nahum. > > > We recently made some changes to our largest delphi 4 application > > and now it does not work under Windows 98. When I say does not > > work I literrly mean that, it won't run any more windows just > > says 'There is not enough memory to start x' or something > > similiar and suggests 'Quit some running programs, and then try > > again". The problem is that it happens as soon as you double > > click on the app or run it from the delphi ide. I've put a break > > point on the begin in the dpr and it doesn't even get there. > > It's like win98 is looking at the exe and deciding it can't run > > it - and doesn't give a particullarly helpfull message. Memory > > is not the issue as there is 512mb of it and nothing else running. > > > > So I was just wondering if anyone else had encountered this > > problem and/or maybe had some ideas to diagonse the situation. I > > can provide more info if you want. > > Ah yes, we recently hit this issue with our application. It's > likely not the > .EXE size, rather it's the size of your resource directory. > > Some background, when Win9x loads a 32-bit PE format EXE or > DLL, it builds a > 16-bit NE format hModule segment for the Win3.1 derived > 16-bit kernel to > work with. You can find documentation about this in Matt > Pietreks' Windows > 95 System Programming Secrets book if you're interested. Anyway, the > executive summary is that this hModule segment is limited to 64K. > > The reason that Delphi apps hit this liimit more than others > is because > Delphi creates an RCDATA resource for every form and > datamodule (i.e. every > .dfm) in your application with classname of the form or datamodule in > question. It's not the size of the .dfm contents that hits > the 64K limit, > rather it's the size of all those names in the resource directory. > > Oh, and there also appear to be strange bugs in the Win9x > code that builds > the hModule surrogate (I've written an application to explore > and dump out > it's contents) - I imagine they don't help either. > > There are a couple of solutions for this issue: > 1) restructure your application to use packages (or DLLs) - > the 64K limit is > per hModule and each 32-bit DLL or EXE gets it's own surrogate 16-bit > hModule. If you're patching the VCL (like we are) or using any form of > exception trapping and tracing (like we are), packages may complicate > matters somewhat. > > 3) rename your forms and datamodules to use shorter names to > reduce the > resource directory size and hope that brings you under the limit. I > personally think this is a horrible idea but it might be just enough. > > 2) strip out any unused resources and see if that gets you > back under the > 64K limit. Whilst Delphi's linker is smart about linking out > unused code > (unless you use packages that is), it can't tell which resources you > actually use or not. So all the resources for every VCL unit you use a > single component from are being linked into your application > whether you > need them or not. > > Max and I whipped up a tool to explore the resource directory > of a 32-bit PE > executable and show the resource directory and since added > code to calculate > the approximate 16-bit NE resource directory size it would > need based on the > available documentation and some spelunking. Due to the bugs > in the Win9x > code which builds the table, it's somewhat approximate for > big directories > but it enabled us to see all the junk resources we could kick > out and that > was enough to bring us back under the limit. > > I can see you a copy of ResTree (our tool) if you like. > > We also plan to inform our users that this is the last major > version where > we will continue to support Win9x :-) > > TTFN, > Paul. >
<<attachment: winmail.dat>>
_______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
