Re: Windows API Translation
Stewart Gordon wrote: On 08/02/2011 22:31, Matthias Pleh wrote: snip VisualD has some code for automated winapi-conversion: quoteto 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...
Re: Windows API Translation
On 08/02/2011 22:31, Matthias Pleh wrote: snip VisualD has some code for automated winapi-conversion: quoteto 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.
Re: Windows API Translation
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: quoteto 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
Re: Windows API Translation
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: quoteto 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
Re: Windows API Translation
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, Vladimirmailto:vladi...@thecybershadow.net
Re: Windows API Translation
I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? They definitely need to be merged.
Re: Windows API Translation
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.
Re: Windows API Translation
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 :(
Re: Windows API Translation
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?
Re: Windows API Translation
On Tue, Feb 8, 2011 at 10:40 AM, Kagamin s...@here.lot wrote: 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? 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.
Re: Windows API Translation
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
Re: Windows API Translation
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);
Re: Windows API Translation
On 2/8/11, Andrew Wiley debio...@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: That's odd, I was just going through its documentation yesterday because I need it for a personal project. I've also looked at ReadDirectoryChangesW, which should give me the exact file or folder that was changed. Just in case you haven't found already (or if someone else is interested), there's a few good pages describing these functions: FindFirstChangeNotification function: http://msdn.microsoft.com/en-us/library/aa364417%28v=vs.85%29.aspx Example C++ Code: http://msdn.microsoft.com/en-us/library/aa365261%28v=vs.85%29.aspx FindNextChangeNotification function: http://msdn.microsoft.com/en-us/library/aa364427%28v=vs.85%29.aspx ReadDirectoryChangesW function: http://msdn.microsoft.com/en-us/library/aa365465%28v=vs.85%29.aspx FILE_NOTIFY_INFORMATION Structure: http://msdn.microsoft.com/en-us/library/aa364391%28v=vs.85%29.aspx WaitForMultipleObjects Function: http://msdn.microsoft.com/en-us/library/ms687025%28v=vs.85%29.aspx http://stackoverflow.com/questions/342668/how-to-use-readdirectorychangesw-method-with-completion-routine The C++ example of FindFirstChangeNotification works great. There's no I/O polling going on, the thread is waiting for WaitForMultipleObjects to return and get notifications from the OS for any file/folder changes, and they're pretty much instantaneous.
Re: Windows API Translation
Btw, how up-to-date are the import libs in windows/lib that ships with DMD2? Can they be used with e.g. Win7?
Re: Windows API Translation
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.
Re: Windows API Translation
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.
Re: Windows API Translation
On 2/8/11, Don nos...@nospam.com 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. So, implib /s on my system DLLs, right? Does anyone have a script to do that? I'm lazy. :p
Re: Windows API Translation
So, implib /s on my system DLLs, right? Does anyone have a script to do that? I'm lazy. :p Something like: FOR %%i IN (*.dll) DO implib /system %%~ni.lib %%i
Re: Windows API Translation
That's exactly what I did a minute ago: For %%a in (*.dll) do implib /s %%~na.lib %%a :) Gotta hate that cryptic batch syntax though.. I am still missing these two though: uuid.dll winspool.dll From what I can tell uuid is used with COM, but it isn't installed on my system for some reason. Winspool is for printers, right? I don't care about that one.
Re: Windows API Translation
Nevermind, uuid isn't an import library, apparently it holds some GUID's for COM objects(?). Replacing those import libs now seems like a bad idea because phobos can't find a ton of symbols. Eh, it's never easy, is it..
Re: Windows API Translation
Correction: Not Phobos, druntime.
Re: Windows API Translation
How many corrections? I thought snn.lib was druntime in disguise. It's Digital Mars C/C++ runtime library. I'll just put all the originals back.
Re: Windows API Translation
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.
Re: Windows API Translation
fwiw, I've had more luck using coffimplib on the libs from the Windows platform SDK than i have using implib on the dlls.
Re: Windows API Translation
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: quoteto 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
Re: Windows API Translation
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.
Re: Windows API Translation
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. True, but MS never changes the api's, so they work and continue to work fine.
Re: Windows API Translation
I don't know why I thought this would be easy. ReadDirectoryChangesW
is a b**ch to use. Someone even wrote a wrapper for it:
http://www.codeproject.com/KB/files/directorychangewatcher.aspx
It clocks in at over 1500 lines. For a single API function. Yikes!
Compare this to .Net's FileSystemWatcher. Create an object, pass a
delegate, and get back some info: Console.WriteLine(File: {0} renamed
to {1}, e.OldFullPath, e.FullPath);
Your work is done.
With ReadDirectoryChangesW I have to keep count of bytes to skip
forward, use casts and keep separate pointers and length variables.
Not to mention the function is not fully documented as this long blog
post shows:
http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html
Re: Windows API Translation
On Tue, Feb 8, 2011 at 7:16 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I don't know why I thought this would be easy. ReadDirectoryChangesW
is a b**ch to use. Someone even wrote a wrapper for it:
http://www.codeproject.com/KB/files/directorychangewatcher.aspx
It clocks in at over 1500 lines. For a single API function. Yikes!
Compare this to .Net's FileSystemWatcher. Create an object, pass a
delegate, and get back some info: Console.WriteLine(File: {0} renamed
to {1}, e.OldFullPath, e.FullPath);
Your work is done.
With ReadDirectoryChangesW I have to keep count of bytes to skip
forward, use casts and keep separate pointers and length variables.
Not to mention the function is not fully documented as this long blog
post shows:
http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html
Honestly, API-wise, it feels a lot like most of the Posix C APIs (I'm
using iNotify on Linux for this already), but less polished. That bit
about missing events though, that's pretty crappy.
And I love how their docs imply that you can somehow use it with
FindFirstChangeNotification.
From reading about the performance problems, it seems that the lovely
thin layer I built on iNotify on Linux might have to have to become a
multithreaded heavy backend on Windows. Ah well.
Windows API Translation
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.
Re: Windows API Translation
On Tue, 08 Feb 2011 09:10:02 +0200, Andrew Wiley debio...@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,
Vladimirmailto:vladi...@thecybershadow.net
Re: Windows API Translation
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
Re: Windows API Translation
On Tue, 08 Feb 2011 09:36:54 +0200, Vladimir Panteleev wrote:
On Tue, 08 Feb 2011 09:10:02 +0200, Andrew Wiley debio...@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
