Difference between revisions of "Windows API units"

From Free Pascal wiki
Jump to navigationJump to search
(New page: {{RTL}} 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 and what changes t...)
 
Line 13: Line 13:
 
In older versions, the both winunits packages were merged in one package (base/winunits or extra/winunits, the location changed a few times), also in older versions more windows units were in the RTL directory. This has now been reduced to the ones that the RTL actually has depandancies on.
 
In older versions, the both winunits packages were merged in one package (base/winunits or extra/winunits, the location changed a few times), also in older versions more windows units were in the RTL directory. This has now been reduced to the ones that the RTL actually has depandancies on.
  
== reducing the Windows unit ===
+
== Reducing the Windows unit ==
  
 
In the past, before the existance of winunits-base, 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 they are already removed from the Windows unit. This might slightly reduce 2.2.0 compability of 2.2.2 a bit, but solves dangerous situations where the order of commctrl and windows in the uses clause matter.  
 
In the past, before the existance of winunits-base, 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 they are already removed from the Windows unit. This might slightly reduce 2.2.0 compability of 2.2.2 a bit, but solves dangerous situations where the order of commctrl and windows in the uses clause matter.  
 
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.
 
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.  
+
Specifically, listview_* functions were removed (already in commctrl) and openfilename* and some other precooked dialogue related functions were moved to commdlg.
  
 
== Expansion ==
 
== Expansion ==

Revision as of 19:21, 29 March 2009

Deutsch (de) English (en) español (es) français (fr) Bahasa Indonesia (id) 日本語 (ja) русский (ru)

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 and what changes to these units. In general this page will describe the current (SVN) status of 2.2.1+, and only detail the situation before when it is needed for the understanding of the current structure. Here and there I will describe what changed from 2.2.0 to the current situation though.

Organization

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 because these units contain functions used by the RTL.
  • The other units from FPC origin reside in a package "winunits-base"
  • The current version of the (independant) JEDI windows API translation resides in a package winunits-jedi.

In older versions, the both winunits packages were merged in one package (base/winunits or extra/winunits, the location changed a few times), also in older versions more windows units were in the RTL directory. This has now been reduced to the ones that the RTL actually has depandancies on.

Reducing the Windows unit

In the past, before the existance of winunits-base, 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 they are already removed from the Windows unit. This might slightly reduce 2.2.0 compability of 2.2.2 a bit, but solves dangerous situations where the order of commctrl and windows in the uses clause matter. 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.

Expansion

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.