Windows API units
Note: this article probably will need to be updated to reflect the current (FPC 2.7.1) situation. Also, it apparently was called RTL - does another article called RTL need to be added/substituted? BigChimp, October 2012
Under windows (win32/win64/wince) one can access the Windows API via several Windows API units. This article will try to sketch an overview of what is available in FPC. Lazarus of course also supports Windows APIs (e.g. to show dialogs) which is not covered here.
In general this page will describe the status as of FPC 2.2.1+, and only detail the earlier situation when it is needed for the understanding of the current structure.
The Windows API units have been redivided over directories/packages several times, currently the situation is as follows:
- The windows and some other units (winsock,winsock2) reside in the RTL. This is because these units contain functions used by the RTL.
- The other units originating from FPC reside in a package winunits-base and some might be in rtl-extra
- The current version of the (independent) JEDI windows API translation resides in a package winunits-jedi.
In older versions, both winunits packages were merged in one package (base/winunits or extra/winunits, depending on FPC version). In older versions more windows units were present in the RTL directory. This has now been reduced to the ones that the RTL actually has dependencies on.
Reducing the Windows unit
In the past, before winunits-base existed, most missing API symbols were added to unit windows. Currently efforts are underway to remove these symbols and put them in the unit where Delphi puts them (comdlg, commctrl, activex). To avoid scoping problems (e.g. dangerous situations where the order of commctrl and windows in the uses clause matter) they are already removed from the Windows unit. This poses a barrier for Lazarus to use the winunits-base units, which was unacceptable. On top of this, the Windows unit versions weren't translated properly.
Specifically, listview_* functions were removed (already in commctrl) and openfilename* and some other precooked dialogue related functions were moved to commdlg.
Since 2.0.4, the winunits-base units have been vastly expanded. Most notably retranslations of many headers were done to take advantage of better 2.0 support. (unicode versions now useful due to widestrings, interfaces, winbools/bytebools), and numerous small fixes that improve the Delphi compability of the declarations.
This process will probably continue for a while.
The 3.2.x series has mostly some organic fixes and enhancements to the windows header units.
It should also enable structured exception handling which should improve handling COM objects that use exceptions internally