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 "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
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 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>


<snip>

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>


 <snip>
 
 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 reply Trass3r <un known.com> writes:
 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.
Feb 08 2011
parent reply Kagamin <spam here.lot> writes:
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?
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 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=




ceives 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?


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  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  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