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
