Each port that allows the usage of dynamic libraries should call InitSystemDynLibs during initialization of the System unit.
The DynLibs unit has been adjusted to be a forwarder for the functions that now reside in the System unit (for backwards compatiblity just in case). Additionally the unit will register the DynLibsManager if it doesn't reside in the System unit anyway.
Currently only the Windows targets (Win32, Win64 and WinCE) implement the DynLibsManager inside the System unit. For other systems using the LoadLibrary, etc. functions will lead to a run error/exception.
If a port wants to implement its own DynLibsManager then it needs to define DISABLE_NO_DYNLIBS_MANAGER. TLibHandle, NilHandle and optionally TOrdinalEntry (it's set to SizeUInt otherwise) should be defined in sysdlh.inc which needs to be enabled using the define FPC_SYSTEM_HAS_SYSDLH (because there are targets which have FEATURE_DYNLIBS enabled, but don't support them... e.g. powerpc-wii -.-).
The DynLibsManager contains methods for loading a library based on a RawByteString and based on a UnicodeString. BOTH should be implemented, but internally one can forward to the other.
The loading by ordinal *can* be be implemented. If it is set to Nil then the implementation of GetProcAddress(lib,ordinal) will return Nil.
+ new functions SetDynLibsManager and GetDynLibsManager to set and retrieve the current DynLibsManager
* provide interface of DynLibs unit in unit System
git-svn-id: trunk@29613 -
rtl/win/sysos.inc:
+ add definition of TSystemInfo structure
+ add import of GetSystemInfo
+ add implementation of GetCPUCount which returns value for number of processors retrieved by GetSystemInfo
git-svn-id: trunk@28643 -
* Deprecated StartupInfo variable because it is not there for Delphi compatibility (Delphi apparently does not have such variable in interface of its System unit), and we don't have other reasons to export non-portable stuff.
git-svn-id: trunk@26810 -
o since we always use UTF-16 for OS file API calls, this will only affect
possible intermediate code page conversions inside RTL routines and hence
prevent potential data loss. This was already the same for NativeNT and
WinCE, which are in the same boat
o DefaultRTLFileSystemCodePage, which specifies the code page used to return
strings from single byte RTL routines, remains CP_ACP and hence nothing
will change as far as programs using the RTL are concerned
git-svn-id: trunk@26377 -
Although basic things work (no regressions in test suite, also with TEST_OPT=-O2), there are some secondary issues/TODOs:
- Exception frame around PASCALMAIN is not properly removed in DLLs
- No stack traces yet
- Stack overallocated in finalizer procedures, their entry/exit code needs cleanup
- Signals unit is probably completely broken.
git-svn-id: trunk@26225 -
