www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows API Translation

reply Andrew Wiley <debio264 gmail.com> writes:
I'm trying to use the Windows file change notification API from D, and
I'm having trouble translating Microsoft's macro-laden signatures into
D. I thought I had it figured out, but optlink says otherwise:
The original function is this:

HANDLE WINAPI FindFirstChangeNotification(
  __in=A0=A0LPCTSTR lpPathName,
  __in=A0=A0BOOL bWatchSubtree,
  __in=A0=A0DWORD dwNotifyFilter
);

I translated it into:

extern(Windows) {
uint FindFirstChangeNotification(
	const(char)* lpPathName,
	bool bWatchSubtree,
	uint dwNotifyFilter
);
}

Optlink is giving me undefined symbol errors, but I can't seem to
figure out what I have wrong. Any help would be appreciated.
Feb 07 2011
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 08 Feb 2011 01:10:02 -0600, Andrew Wiley wrote:

 I'm trying to use the Windows file change notification API from D, and
 I'm having trouble translating Microsoft's macro-laden signatures into
 D. I thought I had it figured out, but optlink says otherwise: The
 original function is this:
 
 HANDLE WINAPI FindFirstChangeNotification(
   __in  LPCTSTR lpPathName,
   __in  BOOL bWatchSubtree,
   __in  DWORD dwNotifyFilter
 );
 
 I translated it into:
 
 extern(Windows) {
 uint FindFirstChangeNotification(
 	const(char)* lpPathName,
 	bool bWatchSubtree,
 	uint dwNotifyFilter
 );
 }
 
 Optlink is giving me undefined symbol errors, but I can't seem to figure
 out what I have wrong. Any help would be appreciated.

I think you have to use either the FindFirstChangeNotificationW function (Unicode) or FindFirstChangeNotificationA function (ANSI) -- probably the former. Also, if you import core.sys.windows.windows, you can use the Windows API types directly: import core.sys.windows.windows; extern(Windows) HANDLE FindFirstChangeNotification( LPCWSTR lpPathName, BOOL bWatchSubtree, DWORD dwNotifyFilter ); Note that I replaced LPCTSTR with LPCWSTR, which is a UTF-16 string, i.e. an alias for const(wchar)* and not const(char)*. This means that you have to use the std.utf.toUTF16z() function to convert normal strings before passing them to the function. -Lars
Feb 07 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 08 Feb 2011 09:10:02 +0200, Andrew Wiley <debio264 gmail.com>  
wrote:

 I'm trying to use the Windows file change notification API from D, and
 I'm having trouble translating Microsoft's macro-laden signatures into
 D. I thought I had it figured out, but optlink says otherwise:
 The original function is this:

 HANDLE WINAPI FindFirstChangeNotification(
   __in  LPCTSTR lpPathName,
   __in  BOOL bWatchSubtree,
   __in  DWORD dwNotifyFilter
 );

 I translated it into:

 extern(Windows) {
 uint FindFirstChangeNotification(
 	const(char)* lpPathName,
 	bool bWatchSubtree,
 	uint dwNotifyFilter
 );
 }

 Optlink is giving me undefined symbol errors, but I can't seem to
 figure out what I have wrong. Any help would be appreciated.

Are you linking with the appropriate import library? You may also want to have a look at the Win32 bindings project (which also has this function among many others): http://dsource.org/projects/bindings/wiki/WindowsApi -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Feb 07 2011
parent reply Trass3r <un known.com> writes:
 I wonder if these bindings would be suitable for inclusion in the
core.sys.windows package?

They definitely need to be merged.
Feb 08 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 08/02/2011 12:25, Trass3r wrote:
 I wonder if these bindings would be suitable for inclusion in the
core.sys.windows package?

They definitely need to be merged.

Merged? The whole point of the bindings project is that it will one day be complete. As such, it needs to _replace_ the current std.c.windows.* and core.sys.windows.*. Stewart.
Feb 08 2011
parent reply Matthias Pleh <sufu alter.com> writes:
Am 08.02.2011 22:37, schrieb Stewart Gordon:
 On 08/02/2011 12:25, Trass3r wrote:
 I wonder if these bindings would be suitable for inclusion in the
 core.sys.windows package?

They definitely need to be merged.

Merged? The whole point of the bindings project is that it will one day be complete. As such, it needs to _replace_ the current std.c.windows.* and core.sys.windows.*. Stewart.

VisualD has some code for automated winapi-conversion: <quote>to build the necessary D translations from the Windows and Visual Studio SDK</quote> http://www.dsource.org/projects/visuald/wiki/Build_from_source greets Matthias
Feb 08 2011
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Matthias Pleh wrote:
 Am 08.02.2011 22:37, schrieb Stewart Gordon:
 On 08/02/2011 12:25, Trass3r wrote:
 I wonder if these bindings would be suitable for inclusion in the
 core.sys.windows package?

They definitely need to be merged.

Merged? The whole point of the bindings project is that it will one day be complete. As such, it needs to _replace_ the current std.c.windows.* and core.sys.windows.*. Stewart.

VisualD has some code for automated winapi-conversion: <quote>to build the necessary D translations from the Windows and Visual Studio SDK</quote> http://www.dsource.org/projects/visuald/wiki/Build_from_source

Yes, building Visual D uses a tool that machine translates about 40 header and idl files from the Windows SDK (I tweaked it for versions 6.0A and 7.1A) and the full Visual Studio SDK. It filters out unused branches (mostly 64-bit), but tries to keep the rest similar to the original headers including comments. Preprocessor macros with arguments are translated to template functions. It uses "const" for most declaration including GUIDs, so you need to build a library and cannot simply import them in your project. Updating the import libraries needs coffimplib, implib32 does not work well enough. How well does SWIG handle the Windows API headers? Don wrote:
 Andrej Mitrovic wrote:
 Btw, how up-to-date are the import libs in windows/lib that ships with
 DMD2? Can they be used with e.g. Win7?

They are horribly outdated. But I have a vague recollection that Walter has explicit permission from Microsoft to redistribute updated versions.

If Walter not only has permission to distribute import libraries, but also the API header files, I could tweak it to support more of the 1200 header files (it often needs one or two special cases per file because of some preprocessor magic), so it could go into the dmd distribution. It is probably not perfectly compatible with core.sys.windows, though. Assuming redistribution is a problem, I was planning to add some conversion wizard to Visual D to let the user create the files from the C headers and libraries. Rainer
Feb 09 2011
parent Don <nospam nospam.com> writes:
Rainer Schuetze wrote:
 
 Matthias Pleh wrote:
 Am 08.02.2011 22:37, schrieb Stewart Gordon:
 On 08/02/2011 12:25, Trass3r wrote:
 I wonder if these bindings would be suitable for inclusion in the
 core.sys.windows package?

They definitely need to be merged.

Merged? The whole point of the bindings project is that it will one day be complete. As such, it needs to _replace_ the current std.c.windows.* and core.sys.windows.*. Stewart.

VisualD has some code for automated winapi-conversion: <quote>to build the necessary D translations from the Windows and Visual Studio SDK</quote> http://www.dsource.org/projects/visuald/wiki/Build_from_source

Yes, building Visual D uses a tool that machine translates about 40 header and idl files from the Windows SDK (I tweaked it for versions 6.0A and 7.1A) and the full Visual Studio SDK. It filters out unused branches (mostly 64-bit), but tries to keep the rest similar to the original headers including comments. Preprocessor macros with arguments are translated to template functions. It uses "const" for most declaration including GUIDs, so you need to build a library and cannot simply import them in your project. Updating the import libraries needs coffimplib, implib32 does not work well enough. How well does SWIG handle the Windows API headers? Don wrote: > Andrej Mitrovic wrote: >> Btw, how up-to-date are the import libs in windows/lib that ships with >> DMD2? Can they be used with e.g. Win7? > > They are horribly outdated. But I have a vague recollection that Walter > has explicit permission from Microsoft to redistribute updated versions. If Walter not only has permission to distribute import libraries, but also the API header files,

I believe he does. But it was a newsgroup post many years ago, I don't trust my memory on that.
 I could tweak it to support more of the 1200
 header files (it often needs one or two special cases per file because 
 of some preprocessor magic), so it could go into the dmd distribution. 
 It is probably not perfectly compatible with core.sys.windows, though.
 
 Assuming redistribution is a problem, I was planning to add some 
 conversion wizard to Visual D to let the user create the files from the 
 C headers and libraries.
 
 Rainer

Feb 09 2011
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 08/02/2011 22:31, Matthias Pleh wrote:
<snip>
 VisualD has some code for automated winapi-conversion:

 <quote>to build the necessary D translations from the Windows and Visual
Studio SDK</quote>

Firstly, can this be used to build D translations from headers other than M$'s own? The win32 translations in the bindings project is based on the MinGW headers, therefore avoiding copyright issues. Secondly, automated translation leaves a lot to be desired, and the whole point of the project is to avoid these shortcomings. Stewart.
Feb 10 2011
parent Rainer Schuetze <r.sagitario gmx.de> writes:
Stewart Gordon wrote:
 On 08/02/2011 22:31, Matthias Pleh wrote:
 <snip>
 VisualD has some code for automated winapi-conversion:

 <quote>to build the necessary D translations from the Windows and 
 Visual Studio SDK</quote>

Firstly, can this be used to build D translations from headers other than M$'s own? The win32 translations in the bindings project is based on the MinGW headers, therefore avoiding copyright issues.

I guess it can be tweaked without too much effort to work with the MinGW headers. It seems, the mingw-files are missing a lot from the SDK, though. The win32api-3.15 folder has less than 3 MB in <250 files, while the SDK v6.0A which comes with VS2008 has >60MB, just counting the 1200 header files. The current v7.1 has a lot more, but I don't have it on this computer to check.
 
 Secondly, automated translation leaves a lot to be desired, and the 
 whole point of the project is to avoid these shortcomings.
 

The mingw win32api files are very terse, so there is not a lot to be lost. But the conversion tool tries to keep comments and formatting as much as possible. Agreed, you can't be sure translation was correct in all cases, but there is so much of it, you don't want to do it manually...
Feb 12 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 08 Feb 2011 09:36:54 +0200, Vladimir Panteleev wrote:

 On Tue, 08 Feb 2011 09:10:02 +0200, Andrew Wiley <debio264 gmail.com>
 wrote:
 
 I'm trying to use the Windows file change notification API from D, and
 I'm having trouble translating Microsoft's macro-laden signatures into
 D. I thought I had it figured out, but optlink says otherwise: The
 original function is this:

 HANDLE WINAPI FindFirstChangeNotification(
   __in  LPCTSTR lpPathName,
   __in  BOOL bWatchSubtree,
   __in  DWORD dwNotifyFilter
 );

 I translated it into:

 extern(Windows) {
 uint FindFirstChangeNotification(
 	const(char)* lpPathName,
 	bool bWatchSubtree,
 	uint dwNotifyFilter
 );
 }

 Optlink is giving me undefined symbol errors, but I can't seem to
 figure out what I have wrong. Any help would be appreciated.

Are you linking with the appropriate import library? You may also want to have a look at the Win32 bindings project (which also has this function among many others): http://dsource.org/projects/bindings/wiki/WindowsApi

Wow, I didn't know this existed. I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? Currently, core.sys.windows.windows only contains a small subset of the Windows API. -Lars
Feb 07 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 08 Feb 2011 09:52:24 +0200, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 Wow, I didn't know this existed.  I wonder if these bindings would be
 suitable for inclusion in the core.sys.windows package?  Currently,
 core.sys.windows.windows only contains a small subset of the Windows API.

That would be great. I had to use Tango, Phobos (via Tangobos), these bindings and dwin in the same project once, and three of those four had their own definitions of the basic Win32 types. Not fun. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Feb 08 2011
parent reply novice2 <sorry noem.ail> writes:
 Wow, I didn't know this existed.  I wonder if these bindings would be
 suitable for inclusion in the core.sys.windows package?  Currently,
 core.sys.windows.windows only contains a small subset of the 


one bad (imho) thing - functions parameters names removed :( just types remains. it is make self-documentation or fast-look-to-remember harder :(
Feb 08 2011
parent Don <nospam nospam.com> writes:
novice2 wrote:
 Wow, I didn't know this existed.  I wonder if these bindings would be
 suitable for inclusion in the core.sys.windows package?  Currently,
 core.sys.windows.windows only contains a small subset of the 


one bad (imho) thing - functions parameters names removed :( just types remains. it is make self-documentation or fast-look-to-remember harder :(

That's because the code is derived from MingW, not from the Microsoft headers.
Feb 08 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 HANDLE WINAPI FindFirstChangeNotification(
   __inLPCTSTR lpPathName,
   __inBOOL bWatchSubtree,
   __inDWORD dwNotifyFilter
 );

FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not.
Feb 08 2011
parent reply Kagamin <spam here.lot> writes:
Trass3r Wrote:

 HANDLE WINAPI FindFirstChangeNotification(
   __inLPCTSTR lpPathName,
   __inBOOL bWatchSubtree,
   __inDWORD dwNotifyFilter
 );

FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not.

D string encoding is not configurable. What configuration are you talking about?
Feb 08 2011
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 08.02.2011 17:40, schrieb Kagamin:
 Trass3r Wrote:

  >  HANDLE WINAPI FindFirstChangeNotification(
  >    __in  LPCTSTR lpPathName,
  >    __in  BOOL bWatchSubtree,
  >    __in  DWORD dwNotifyFilter
  >  );

  FindFirstChangeNotification is - like any other Windows function that
receives a string - just an alias that points to a version with suffix W or A
depending on whether your project is configured to be Unicode or not.

D string encoding is not configurable. What configuration are you talking about?

he talks about stuff like that (from winbase.h - vs2010) WINBASEAPI __out HANDLE WINAPI CreateFileA( __in LPCSTR lpFileName, __in DWORD dwDesiredAccess, __in DWORD dwShareMode, __in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes, __in DWORD dwCreationDisposition, __in DWORD dwFlagsAndAttributes, __in_opt HANDLE hTemplateFile ); WINBASEAPI __out HANDLE WINAPI CreateFileW( __in LPCWSTR lpFileName, __in DWORD dwDesiredAccess, __in DWORD dwShareMode, __in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes, __in DWORD dwCreationDisposition, __in DWORD dwFlagsAndAttributes, __in_opt HANDLE hTemplateFile ); #ifdef UNICODE #define CreateFile CreateFileW #else #define CreateFile CreateFileA #endif // !UNICODE not the string itself - look at lpFileName
Feb 08 2011
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 08.02.2011 17:40, schrieb Kagamin:
 Trass3r Wrote:

  >  HANDLE WINAPI FindFirstChangeNotification(
  >    __in  LPCTSTR lpPathName,
  >    __in  BOOL bWatchSubtree,
  >    __in  DWORD dwNotifyFilter
  >  );

  FindFirstChangeNotification is - like any other Windows function that
receives a string - just an alias that points to a version with suffix W or A
depending on whether your project is configured to be Unicode or not.

D string encoding is not configurable. What configuration are you talking about?

or these typical win-api phobos constructs from std.file auto h = useWfuncs ? CreateFileW(std.utf.toUTF16z(name), defaults) : CreateFileA(toMBSz(name), defaults);
Feb 08 2011
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Tue, Feb 8, 2011 at 10:40 AM, Kagamin <spam here.lot> wrote:
 Trass3r Wrote:

 HANDLE WINAPI FindFirstChangeNotification(
 =A0 __in=A0=A0LPCTSTR lpPathName,
 =A0 __in=A0=A0BOOL bWatchSubtree,
 =A0 __in=A0=A0DWORD dwNotifyFilter
 );

FindFirstChangeNotification is - like any other Windows function that re=


depending on whether your project is configured to be Unicode or not.
 D string encoding is not configurable. What configuration are you talking=


It's a setting in Visual Studio that translates into a compiler switch for Visual C++, or such is my understanding. He was talking about configuration on the Microsoft C/C++ side, not the D side. In D, I just have to add a suffix to the name to choose the one I want.
Feb 08 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrew Wiley wrote:
 I'm trying to use the Windows file change notification API from D, and
 I'm having trouble translating Microsoft's macro-laden signatures into
 D. I thought I had it figured out, but optlink says otherwise:
 The original function is this:
 
 HANDLE WINAPI FindFirstChangeNotification(
   __in  LPCTSTR lpPathName,
   __in  BOOL bWatchSubtree,
   __in  DWORD dwNotifyFilter
 );
 
 I translated it into:
 
 extern(Windows) {
 uint FindFirstChangeNotification(
 	const(char)* lpPathName,
 	bool bWatchSubtree,
 	uint dwNotifyFilter
 );
 }
 
 Optlink is giving me undefined symbol errors, but I can't seem to
 figure out what I have wrong. Any help would be appreciated.

Here is the declaration from \dm\include\win32\winbase.h: WINBASEAPI HANDLE WINAPI FindFirstChangeNotificationA( LPCSTR lpPathName, BOOL bWatchSubtree, DWORD dwNotifyFilter ); WINBASEAPI HANDLE WINAPI FindFirstChangeNotificationW( LPCWSTR lpPathName, BOOL bWatchSubtree, DWORD dwNotifyFilter ); #ifdef UNICODE #define FindFirstChangeNotification FindFirstChangeNotificationW #else #define FindFirstChangeNotification FindFirstChangeNotificationA #endif // !UNICODE Note the W postfix and the LPCWSTR arg, which should be wchar* (in D). With the Digital Mars C compiler, getting the de-macro'd version is easy: dmc -c foo.c -e -l and the macro expanded version will be written to foo.lst. Very handy.
Feb 08 2011