> > If you meant having many libs of different version exist > side-by-side, > > .NET runtime supports it, but Win32 itself doesn't > > Most unixes also have it. The point is that it kind of > defeats the purpose. > Having 20+ libraries called fpcrtl-xyz.dll (or > fpcrtl.so.x.y.z on unixes) defeats the purpose of a shared > library: saving disk and (more importantly) memory space by > factoring out common code. > > If we'd know that the fpcrtl.so (or .dll) interface will stay > the same in the next 5 years, it makes sense to distribute > this. Since the interface changes still wildly, it's a bad idea. > > Look at Delphi packages: as soon as the interface of a > package changes, you must re-compile all the binaries that > use it. The same would be true for FPC. I can assure you this > is a major headache when distributing apps. >
Indeed, what Delphi does sucks too, I sell VCL components (binary only) for QuickTime and QuickTimeVR (QTVR) and have to provide a separate version for each Delphi version (@[EMAIL PROTECTED]@#). I also have the same components as ActiveX controls (wrapping the VCL ones in them [made using Delphi's nice AX wizard and only added property pages, which I wonder why normal VCL components don't have as a concept]) and they're much easier to maintain, just one build for all clients (Office, Delphi, .NET etc.). The problem with the ActiveX is that you have to install them at the user's machine, so running from CD with zero footprint isn't possible (there's a work arround with products like "thinstall" that provide a small OS wrapper [just 300k for new version of thinstall I read] arround the exe that uses a virtual filesystem and registry just for your app, resulting in zero-footprint on user's machine - I suppose they hijack/patch the registry and filesystem [maybe also the disk access] APIs imports of the EXE, maybe also redefine old-style DOS interrupts etc.) With ActiveX too you have problem if you redefine the interfaces you implement, but in general COM promotes the concept of "Immutable interface" (once you publish it, never change it - not remove, nor add stuff). You can extend evolved interfaces from it, but keep implementing it if you want backwards compatibilty. COM itself evolves like that, e.g. with IClassFactoryEx interface (or maybe IClassFactory2, don't remember the name) that most probably (though not necessery) descends from IClassFactory etc. I'd really love to be able to sell components for Lazarus too, but seems impossible at the moment (I usually opensource the core functionality and have the components provide extra features like I did with JEDI-QuickTime that came out of my QT4Delphi [now QT4All] sourcebase). Maybe if Lazarus could host ActiveX controls (not sure if the form designer now supports such a thing, although I think FPC does support ActiveX controls more or less) cheers, George ---------------- George Birbilis ([EMAIL PROTECTED]) Computer & Informatics Engineer Microsoft MVP J# for 2004-2007 Borland "Spirit of Delphi" 3D, QuickTime, QTVR, Java, Delphi, ActiveX, .NET components, Robotics http://www.kagi.com/birbilis http://birbilis.spaces.live.com _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
