mORMot Open Source

We're currently preparing FPC 3.2.4, so would you please test whether the current FPC 3.2.3 fixes the Variant related problems correctly?

Please note that by assuming that OSPOSIX is the opposite of OSWINDOWS you're precluding the use of systems that are neither, but would be able to use mORMot in theory (mainly modern OS/2 systems like eComStation and modern Amigas like AROS or MorphOS). If you don't want to support them right away it would be better to simple error out with an $error in the $else case instead of having undefined behavior for them. FPC's define for POSIX compatible systems is indeed UNIX.

Do you have a self contained example that shows custom variants failing (preferrably not depending on mORMot)? I can't reproduce it with a simple example using TInvokableVariantType. If I have a simple example to reproduce it, I can fix it.

Packages are nothing but DLLs. They just have a few special metadata exports that the RTL can use to correctly identify the package, but aside from this "compiler magic" related stuff they're just plain libraries which export all interface sections of the contained units.

This is wrong for multiple reasons:
- Accessing the disk is slow. And noticing that a page is missing is done using processor exceptions (page fault), thus especially loading code does not work in this way, because not only would an exception happen somewhere inside your code when the execution crosses page borders, but it would lead to the OS having to read from the backing storage before returning control to the application (which would be none the wiser regarding the exception). You can nicely notice this slowdown when your OS runs out of available physical memory and starts to swap pages from/to the pagefile or swap partition.
- Loading from the backing storage would also mean that the OS would need to do relocations again (in case of non-PIC code). But the OS does the relocation only at startup of the application.
- And last the binary on the backing storage might have been changed or the backing storage might have been removed. The former is less a problem on Windows, cause Windows keeps the handle to the file open, but on Linux that is not the case. Thus the file might have been changed which will lead to loading different data. Now imagine if the application runs with high privileges, but can be modified by a normal user...

The features of the dynamic packages are going to be fully compatible. What is going to be different is the partition of the units among the packages cause we'll orient ourselves on our own package structure. Thus for example instead of there being only a Rtl package there'll be the core Rtl, a package for the Unix units that need the C library (as Rtl.C) and then the RTL related packages from the packages directory: Rtl.ObjPas, Rtl.Unicode, Rtl.Generics, Rtl.Console and Rtl.Extra. This simplifies the maintainability for us.
A further difference is that the RTL will do more checks at runtime to decide whether a package is indeed compatible. Many of the instabilities I've witnessed in Delphi (back when I still used it at my old work location) was due to missing consistency checks.

The difference is that dynamic packages allow you to share binary code instead of source code. Though it comes with the price that the packages can't be smartlinked as good as the static application can (all exported code as well as all code referenced by such code needs to be included in a package) and the sum of the size of packages and application can be larger than the size of the static application alone (thus it only really pays off if you really share the packages between applications or if you need a plugin system).

Here is an example for the chmls utility provided by FPC when compiled with packages for Win64 (sizes are in Byte):

Without packages
 615936 chmls.exe

With packages
  85131 chmls.exe
1419896 chm.dll
1187518 fcl.base.dll
 568559 fcl.res.dll
1602915 fcl.xml.dll
   8347 rtl.c.dll
  89978 rtl.console.dll
3647275 rtl.dll
 345340 rtl.extra.dll
 459357 rtl.generics.dll
 601446 rtl.objpas.dll

Edit: one thing I forgot: as long as a code change happens only in the implementation part of a unit (and the changed code isn't marked with inline) then a package library can indeed be replaced without rebuilding the application or other packages. If the interface section however changes then the application needs to be recompiled.