re: 5MB+ exe. What you describe is supposedly the case but I don't believe it. Look at your app run in a memory analysis program and you'll see a lot of memory allocated up front when the exe loads. When you load a form, there is virtually no change in allocated memory. I have put my db access components on the forms that they load with in the hopes that they won't load unless that form is loading. If that were the case, I'd be seeing a lot more memory allocated when that form loads.. With packages, there is no possibility of this happening. I am hoping to see that when I start testing more fully with a package version. It is true that packages will be a larger deployment but the advantages for my intended app far outweigh the disadvantages. I could not put all my functionality into one large exe, it's just not feasible. re: introducing bugs. Being an application developer, I'd better have some faith in my abilities or what good am I? Of course I might introduce bugs.. that is what the debugging process is for. It doesn't just reduce exe size but memory requirements as well. This is a prime consideration for me as my apps are destined for the commercial market, not in-house usage. My problem with Access is that it just doesn't seem very well designed. Maintenance by the user becomes a large issue or unreliability of the product is sure to ensue.. just my experience with it. DJS
Katja Bergman <[EMAIL PROTECTED]> wrote: Well, let's see... I don't think it matters much is an executable is 5MB+ or not. Windows doesn't load it all in memory anyways. If I understood correctly, Windows just maps the part of the harddisk that contains the executable as being part of it's RAM, like a swapfile or so. That way, it only loads things on demand to begin with. Furthermore, it is never easy to keep an executable small if you want a lot of forms and graphical effects in it. And having those inside DLL's or runtime packes seem to have funny side-effects on your application. It is hard to believe but with executables, size doesn't really matter. But size is often related to a huge amount of forms and resources being part of your application. All kinds of bitmaps and icons, for example. The forms that you use. And plenty of other things too. Runtime packages won't solve this problem but might actually make it worse becase now those large runtime libraries become part of your project too. And then I haven't mentioned any possible version conflicts that might occur with those packages. It's that VB developers have called the DLL Hell and Delphi managed to avoid most of this because Delphi doesn't use them most of the time. About third-part components. Sure, you could buy them including source and strip away the parts you don't need but then you'll be losing time on something to just make your executable smaller. And you risk that your modifications might actually add more bugs to your application. And about MS pulling Access off the market... Well, they never succeed at that because Access itself is a complete software solution for generating reports, designing forms and it does a lot more than just store data. Then again, I only use it to store data anyway. Then again, MS also quit developing VB versions for the WIN32 platform and actually seems to abandon the whole WIN32 development marker, with the exception of C++. Not many people like this but MS doesn't seem to listen to them. Sooner or later we'll all be forced to use .NET and I guess that many companies will just refuse any further upgrades because they don't like .NET and they don't like having to buy new hardware because the old stuff is too slow to run .NET applications. My dad told me that there are still plenty of companies that still use olf Pentium I 90 MHZ machines with Windows NT running on it to keep their businesses running. They just refuse to upgrade because the old stuff is still working fine. And I don't blame them. MS might try and abandon those old products but people won't stop using them. Access is extremely popular right now, basically because it's so simple to use. No sane person would trade it in for the more complex SQL Server software. Then again, I'm also interested in seeing if Linux will get a bigger market share or not. I think Linux will grow more and more, but slowly. All it needs is a better user interface for the desktop. With kind regards, X Katja Bergman. --- In [email protected], David Smith <[EMAIL PROTECTED]> wrote: > re: runtime. The same applies to a Delphi app with runtime > packages. I agree that large exe's aren't necessarily a problem > until they rise to the size of 5MB+. Then I think it is foolish not > to use runtime packages. At that size, the large exe will start to > slow things down somewhat. > > re: 3rd party components. I also agree that the large "do > everything" components are contributing largely to this problem. > That is why I buy them with source code and build a new component > with just the features I need. > > I heard that Microsoft is pulling Access from the market and > making everyone migrate to SQL server.. This seems like a good > reason to stay from Access if you're a commercial developer. > > DJS ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups SponsorADVERTISEMENT --------------------------------- Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com [Non-text portions of this message have been removed] ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
