Sorry for posting off topic here, I just can’t find direct mail or other communication channel at your site.

In your article you have mentioned a possible solution to CRTL external functions problem by declaring them as external in msvcrt.dll I’ve found another way how to solve this problem- extract all OBJ files directly from BCB55’s cw32.lib file using tlib as a helper tool. __ftol and _ftol are in ftol.obj This way I was able to bind sqlite3.lib directly into my Delphi project without DLL file (81 obj files, the order of $L is important) The only unresolved external is _wsprintfA wich is in user32.dll

This just leaves #1 - the "mysterious Units" namespace - which make Delphi assemblies look weird to non-Delphi users. They just have to ignore it, as everything else works fine.

Anyway, there are two things which may lead to confusion in Delphi.NET:

1: Delphi always emits an *additional* implicit "Units" name space. If you have a unit "Foo.Bar.Test.pas" containing a class "Test" Then you will see a name space "Foo.Bar" as expected, but also a name space Foo.Bar.Units, also containing a class "Test".

This is not just an "alias", in fact Delphi will mark any class in these "Units" name spaces as "sealed", and these classes appear incomplete (no constructors, etc). In other words this is just some "magic", used by Delphi only. In other .NET languages you should not touch these "Units" namespaces.

2: Error Insight (at least on my machine) does not like stuff like this:

unit Foo.Bar.Class1;

…

end;

unit Foo.Bar.Class2;

interface

…

implementation

uses Class1;

…

This will compile fine, but "uses Class1" will be underlined in red. Errorinsight only likes the full reference - no matter what’s defined as Default Namespace:

unit Foo.Bar.Class2;

interface

…

implementation

uses Foo.Bar.Class1;

…

Actually I M2ed a while before returning to Pascal (then still TP), but that choice was more based on the compiler than the language.

Inner modules and the import behaviour are still the nice parts of M2.