Difference between revisions of "User:AlexVinS/Packages"
From Lazarus wiki
Jump to navigationJump to search(9 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | == | + | == Delphi style == |
− | * New system '' | + | === Platform dependent === |
− | ** os independent, but depends on CPU. Example targets i386- | + | * [[packages|Described here]] |
+ | === Semi-crossplatform === | ||
+ | * New system ''crossplatform''. | ||
+ | ** os independent, but depends on CPU. Example targets i386-crossplatform ia64-crossplatform | ||
* OOP interface (ojpas interfaces based) between host executable and package RTL, extensible to communicate with concrete packages. | * OOP interface (ojpas interfaces based) between host executable and package RTL, extensible to communicate with concrete packages. | ||
* Host executable memory manager shared with package libs. | * Host executable memory manager shared with package libs. | ||
* Package binary file format. | * Package binary file format. | ||
** Require to be fully portable (not depends of target system and cpu) | ** Require to be fully portable (not depends of target system and cpu) | ||
− | * | + | |
+ | ==== Questions ==== | ||
+ | * How exceptions objects should be transfered between executable and packages? | ||
+ | * The package binary format (ELF, FatELF based?) | ||
+ | * Can RTTI help to access objects from exe by package and vice versa? Use only interfaces or macpas external objects? | ||
+ | |||
+ | ==== Known issues ==== | ||
+ | ; win32 | ||
+ | * manually loaded binary must be copied to another location to mark memory executable. On XP SP2+ Vista SP1+ & win7 file mapping object could be created with execute permission. | ||
+ | |||
+ | ==== Links ==== | ||
+ | * [http://www.mikekohn.net/file_formats/magic_elf.php Magic ELF] ELF Loader (should run on win32 too) | ||
+ | |||
+ | === Full crossplatform === | ||
+ | * some kind of byte code, like Java, CLR, LLVM | ||
+ | |||
+ | == C++ style == | ||
+ | * Executable and its plugins shares same rtl in statically linked library (memory manager shared so classes and longstrings can be passed between modules). | ||
+ | * Classes can be imported from dynamic library. It means that macpas extension should be enabled for "normal" classes and objects. | ||
+ | * library should be shipped with set of include files, wich defines interface of exported symbols as .h files in c/c++ do. | ||
+ | |||
+ | [[Category:Proposals|Packages]] |
Latest revision as of 20:05, 24 January 2011
Delphi style
Platform dependent
Semi-crossplatform
- New system crossplatform.
- os independent, but depends on CPU. Example targets i386-crossplatform ia64-crossplatform
- OOP interface (ojpas interfaces based) between host executable and package RTL, extensible to communicate with concrete packages.
- Host executable memory manager shared with package libs.
- Package binary file format.
- Require to be fully portable (not depends of target system and cpu)
Questions
- How exceptions objects should be transfered between executable and packages?
- The package binary format (ELF, FatELF based?)
- Can RTTI help to access objects from exe by package and vice versa? Use only interfaces or macpas external objects?
Known issues
- win32
- manually loaded binary must be copied to another location to mark memory executable. On XP SP2+ Vista SP1+ & win7 file mapping object could be created with execute permission.
Links
- Magic ELF ELF Loader (should run on win32 too)
Full crossplatform
- some kind of byte code, like Java, CLR, LLVM
C++ style
- Executable and its plugins shares same rtl in statically linked library (memory manager shared so classes and longstrings can be passed between modules).
- Classes can be imported from dynamic library. It means that macpas extension should be enabled for "normal" classes and objects.
- library should be shipped with set of include files, wich defines interface of exported symbols as .h files in c/c++ do.