Hi, Nahum.

> 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.

Yeah - I found those google group messages too. They took a bit of
'interpreting' and some delving through the Pietrek tome to figure out
exactly what was going on.
 
> 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.

Interesting idea that would definitely dodge the Win9x resource directory
issue. The quicker form creation is unusual since resources are demand paged
into RAM as necessary anyway...

Personally, I'm leery about seperating code and data into independent files
since users have an uncanny knack for losing one of the files or ending up
with mismatched versions, etc. Generally, this is whilst insisting that
everything is all where it should be thus sending trusting developers on
wild goose chases trying to reproduce non-problems. We avoid using DLLs for
the same reason.

<CYNICAL>
General rule of thumb: Users often lie to support staff - not because
they're deceitful, usually just embarassed or worried about taking blame for
something. Ipso facto, the less things they can lie about (DLLs, resource
files, etc.) the better :-)
</CYNICAL>

TTFN,
  Paul.

<<attachment: winmail.dat>>

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi

Reply via email to