Lan Manager header files (lm*.h).
Reason for this addition is twofold:
Petr's original LM interface unit is still included (JwaLM.pas) for those that are already using it. New development should use either Petr's original units (available from http://www.delphi-jedi.org) or the new units included in this release (the individual JwaLmXYZ.pas units, not JwaLM.pas). Existing applications should continue to use the JwaLM.pas unit as the new units are different in many aspects (e.g. in the conversion of parameters, types and so forth). Eventually JwaLM.pas from Petr will be removed...
Up to date with November 2002 Platform SDK
The units are now up to date with the November 2002 release of the Platform SDK.
This means that the included units are up to date with their equivalent header
files in the PSDK, not that all header files are converted - obviously..
The only files that are not yet up to date are:
The most significant change in this release is the addition of dynamic linking
support for all units. By default dynamic linking is turned off, to turn on
dynamic linking remove the dot in the line:
{.$DEFINE DYNAMIC_LINK}
inside WinDefines.inc. In this release this will turn on dynamic linking for all interface units, in a future release I might add support to contorl this on a unit-by-unit basis. Dynamic linking is supported by using a small assembler stub that loads the DLL on demand only when the routine is actually used. There is no need to call any special initialization routine, all happens automatically. Thanks goes out to the guys in borland.public.delphi.basm for their help in implementing this.
Please note that currently there is no way to find out upfront whether or not a
required library is present on the system other than explicitly testing this
yourself using LoadLibrary(), a future release might add support for this. In
case the required library is not present on the system, an exception is raised.
The exception is either EJwaLoadLibraryError or EJwaGetProcAddressError (both
defined in JwaWinType and descended from EJwaError) if LoadLibrary() or
GetProcAddress() fails respectively. Therefor, you'll need to protect your API
calls using a try...except block like this:
var
H: HANDLE;
begin
try
H := CreateFile(...);
if H <> INVALID_HANDLE_VALUE then
begin
...
CloseHandle(H);
end;
except
on EJwaError do
begin
// Either CreateFile or CloseHandle could not be found, handle that
// situation somehow.
end;
end;
end;
Converting header files is a lot of work which I do completely in my own time. If you've found these units usefull, like the fact that they're completely free, and like to contribute to further development and the conversion of even more header files you can do so in many ways. Contact me at brakelm@chello.nl for further information.
One possible way, and a nice gesture, would be to buy me something of my wish-list.
If you performed the steps above you can start using the units in your application by including the appropriate ones in your uses clause. I personally prefer to use Project Options instead of Environment Options to avoid problems. One known problem is that when you use the Enironment Options method, you might get compiler errors when trying to build the JEDI Code Library.
The most common error you're likely to encounter is: "Incompatible types: 'System.WideChar' and 'JwaWinType'.WideChar" where WideChar is only an example. This is due to the fact that the RTL (e.g. System.pas or Windows.pas) defines the type WideChar differently from WinType.pas. To solve this simply change the declaration in JwaWinType.pas to become an alias for the type in System.pas (or Windows.pas). For example Before:
type
DWORD = Longword;
After:
type
DWORD = Windows.DWORD;
If you look inside JwaWinType.pas you see that I've already done this for the most
common types (using conditional compilation) like this
type
DWORD = {$IFDEF USE_DELPHI_TYPES}Windows.DWORD{$ELSE}Longword{$ENDIF};
therefore it's unlikely you'll run into this problem. However, if you do please
notify me so I can update the interface units.
Please note that these units heavily use conditional compilation. You can globally change some settings, and thereby determine how they get compiled, through the WinDefines.inc include file. An example of this would be to specify an unicode build. There are a few more directives which cannot be set globally (yet), look through the unit itself to find them. Full documentation for all directives will be provided in a later release.
Also note that all LanManager units (LM*.pas) were combined into a single unit LM.pas for convenience. The same applies to the Ads*.pas units which were combined into ActiveDS.pas and all Rpc*.pas files which were combined into Rpc.pas. Furthermore, the LanManager translation was done by Petr Vones and is included with his permission. The WinLDAP unit was created by Luk Vermeulen.
Please be aware that the WinLDAP unit was created by Luk Vermeulen and can only be used and distributed under the MPL license. It's included because of dependencies on this unit. I may convert the header myself one day.