www.digitalmars.com         C & C++   DMDScript  

D - Windows library creation: what am I missing?

reply "Christian Kaiser" <chk online.de> writes:
As a first small test, I wanted to port a C++ registry library to D, and I
encountered the following problems:

a) I did not find any mention which Windows APIs are supported - for
example, RegOpenKeyExA() isn't. Where can such a list be found?

b) Having no preprocessor is a good idea, but for Windows development this
is a pain. When I want to create a library that can be compiled with AND
without using UNICODE, I need to embrace nearly all API calls with the
"version(UNICODE)", which is unnecessary in C. Unless the Windows API is
defined using all "version()" statements replacing the macros, this will
make conversion and programming Windows applications harder than it needs to
be. Do I overlook something?

c) I would like to have a standardized char format for that purpose as TCHAR
is for Windows. At the moment, I use

version (UNICODE)
{
alias wchar syschar;
}
else
{
alias char syschar;
}

but having a standard definition would be better.

d) When I want to separate the declaration from the definition of a class,
how can that be done? class::foo() like in C++ does not compile. I guess
that shows that I did not yet get the idea of D, but when I write a class
that others use, they should only see the declaration. How?

e) compiler enhancement suggestion (see my other thread in the DMC group):
the compiler just tells me "function abc(...) does not match argument types
(...)", but it should even tell me which argument it is that does not match.

A beginner's problems.... :)

Christian
Oct 05 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?



All of the APIS are supported, you might need to wrap them in an extern call
though.


extern (Windows) {

  private alias long LONG;
  LONG RegQueryValueExA(HKEY, LPCSTR, LPDWORD, LPDWORD, LPBYTE, LPDWORD);
  LONG RegOpenKeyExA(HKEY, LPCSTR, DWORD, DWORD, HKEY*);

}

Matthew has a registry lib at http://synesis.com.au/synsoft/d.html.

b) Having no preprocessor is a good idea, but for Windows development this

 is a pain



I dont like #ifdefs and even version statements ( all though the latter is
much prettier! ) , I like to keep two seperate development trees, one with
unicode, one without.


 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use



Not sure what you mean here, TCHAR is a typedef so its not quite standard
either.


 d) When I want to separate the declaration from the definition of a class,
 how can that be done?



See matthews registry lib, I havent looked at them but I imagine you can do
something like

extern (D) {
    // all your functions here

}

and then just have them link to your library ... so the implementation is
hidden.


 e) compiler enhancement suggestion (see my other thread in the DMC group):



Yea id like this too, but i think Walter is probably unbeleivably
swamped,Rome wasnt built in a day ( and they had two people! )

C

"Christian Kaiser" <chk online.de> wrote in message
news:blpnm4$1i4s$1 digitaldaemon.com...

 As a first small test, I wanted to port a C++ registry library to D, and I
 encountered the following problems:

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?

 b) Having no preprocessor is a good idea, but for Windows development this
 is a pain. When I want to create a library that can be compiled with AND
 without using UNICODE, I need to embrace nearly all API calls with the
 "version(UNICODE)", which is unnecessary in C. Unless the Windows API is
 defined using all "version()" statements replacing the macros, this will
 make conversion and programming Windows applications harder than it needs




 be. Do I overlook something?

 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use

 version (UNICODE)
 {
 alias wchar syschar;
 }
 else
 {
 alias char syschar;
 }

 but having a standard definition would be better.

 d) When I want to separate the declaration from the definition of a class,
 how can that be done? class::foo() like in C++ does not compile. I guess
 that shows that I did not yet get the idea of D, but when I write a class
 that others use, they should only see the declaration. How?

 e) compiler enhancement suggestion (see my other thread in the DMC group):
 the compiler just tells me "function abc(...) does not match argument




 (...)", but it should even tell me which argument it is that does not




 A beginner's problems.... :)

 Christian
Oct 05 2003
next sibling parent reply "Christian Kaiser" <chk online.de> writes:
Charles,


 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?



 All of the APIS are supported, you might need to wrap them in an extern




 though.



I know, but actually that's a lot of work -- the Windows API has far more
than 1000 functions...:))

I read the note that a H->D converter needs to be built, so may I assume
that there are only some functions defined up to the moment .
RegCreateKeyExA() was compiled by the D compiler, that's why I wondered when
it complained about RegOpenKeyExA() which is in the same DLL advapi32.dll. I
see no reason for that, and no way to find the reason as there's no header
file I can look at.


 Matthew has a registry lib at http://synesis.com.au/synsoft/d.html.



Nothing is as good for me as a library that has been written by myself.
That's a chance to learn a lot of the new language. Better than getting one
from other places. That comes later :))


 b) Having no preprocessor is a good idea, but for Windows development this

 is a pain



 I dont like #ifdefs and even version statements ( all though the latter is
 much prettier! ) , I like to keep two seperate development trees, one with
 unicode, one without.



Yes and no. Having two trees is usually unnecessary as most of the code (can
be 100% is you don't need to deal with MBCS) is the same, so why having
separate trees? This separation can be perfectly hidden in the declaration
files.

And what seems to be missing at all is that I can call ANSI functions from a
Unicode application and vice versa, which is not supported by the
"version()" branching at the present state; in such a case I would again
need to declare the function manually, or the declaration would have to be
changed according to the C preprocessor:

int getValueW(wchar[] p);
int getValueA(char[] p);
version (UNICODE)
	{
	    alias getValueW getValue;
	}
	else
	{
	    alias getValueA getValue;
	}
so that both are accessible, but only one is matched by the "un-charsetted"
call "getValue". This is really needed for development international
applications, that's what I do. In my example code, "RegCreateKeyExW" is not
compiled, but it should be possible to access it without manual
redeclaration of that API.


 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use



 Not sure what you mean here, TCHAR is a typedef so its not quite standard




Yes, you're right when function declarations never cross "owner's"
boundaries, that is, I create an OBJ file, and I pass the class definition
on to someone else who has a different alias for the Unicode-dependent char
type. It might work, but they need to make an alias again like

alias mysyschar syschar;

to be able to access my functions. And I expect that to be a common problem.
C++ has it easier, as the TCHAR is being mapped to char* or wchar_t
depending on the UNICODE define, and every compiler knows these types. If I
would use a typedef, I'd have a problem in C++ too, then my OBJ files would
use "syschar" which I need to define in the class declaration, and hope that
the user does not have such a typedef (or alias) himself with that name.
Well I never tried that as people only see my plain C DLL API, but D has
mangled function names which might get in the way here.


 d) When I want to separate the declaration from the definition of a







 how can that be done?



 See matthews registry lib, I havent looked at them but I imagine you can




 something like

 extern (D) {
     // all your functions here

 }

 and then just have them link to your library ... so the implementation is
 hidden.



Actually Matthew offers all the declarations, but the definitions are hidden
in his library, so I cannot see how he did it :)


 e) compiler enhancement suggestion (see my other thread in the DMC







 Yea id like this too, but i think Walter is probably unbeleivably
 swamped,Rome wasnt built in a day ( and they had two people! )



Yes, I wrote it in the C group, I am astonished how one person can work at
two compilers successfully at all. It's because I'm used to get helpful
information from the C++ compiler I usually use, who does all that, so I
note when it's missing. I don't need this at the moment :)

Christian
Oct 05 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Matthew has a registry lib at http://synesis.com.au/synsoft/d.html.



 Nothing is as good for me as a library that has been written by myself.
 That's a chance to learn a lot of the new language. Better than getting




 from other places. That comes later :))



I understand the motivation. ;)

Please understand that, at this stage, it is likely that the registry
library will be part of Phobos in the next release of the compiler, so you
may want to consider your time. It might be better to select a lib that we
still need.

However, please don't misunderstand me: I'm not trying to put you off.
Working with something you know is very important, and if the Reg is that
for you, that's the best thing to do.

I just wish we had more people writing these libraries ...
Oct 07 2003
prev sibling parent reply "Sarat Venugopal" <sarat_ng n0spam.huelix.com> writes:
What about using MSLU and just forgetting about the ANSI versions?

Cheers,
Sarat

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:blpoiq$1j6i$1 digitaldaemon.com...

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?



 All of the APIS are supported, you might need to wrap them in an extern




 though.


 extern (Windows) {

   private alias long LONG;
   LONG RegQueryValueExA(HKEY, LPCSTR, LPDWORD, LPDWORD, LPBYTE, LPDWORD);
   LONG RegOpenKeyExA(HKEY, LPCSTR, DWORD, DWORD, HKEY*);

 }

 Matthew has a registry lib at http://synesis.com.au/synsoft/d.html.

 b) Having no preprocessor is a good idea, but for Windows development this

 is a pain



 I dont like #ifdefs and even version statements ( all though the latter is
 much prettier! ) , I like to keep two seperate development trees, one with
 unicode, one without.


 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use



 Not sure what you mean here, TCHAR is a typedef so its not quite standard
 either.


 d) When I want to separate the declaration from the definition of a







 how can that be done?



 See matthews registry lib, I havent looked at them but I imagine you can




 something like

 extern (D) {
     // all your functions here

 }

 and then just have them link to your library ... so the implementation is
 hidden.


 e) compiler enhancement suggestion (see my other thread in the DMC







 Yea id like this too, but i think Walter is probably unbeleivably
 swamped,Rome wasnt built in a day ( and they had two people! )

 C

 "Christian Kaiser" <chk online.de> wrote in message
 news:blpnm4$1i4s$1 digitaldaemon.com...

 As a first small test, I wanted to port a C++ registry library to D, and







 encountered the following problems:

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?

 b) Having no preprocessor is a good idea, but for Windows development







 is a pain. When I want to create a library that can be compiled with AND
 without using UNICODE, I need to embrace nearly all API calls with the
 "version(UNICODE)", which is unnecessary in C. Unless the Windows API is
 defined using all "version()" statements replacing the macros, this will
 make conversion and programming Windows applications harder than it







 to

 be. Do I overlook something?

 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use

 version (UNICODE)
 {
 alias wchar syschar;
 }
 else
 {
 alias char syschar;
 }

 but having a standard definition would be better.

 d) When I want to separate the declaration from the definition of a







 how can that be done? class::foo() like in C++ does not compile. I guess
 that shows that I did not yet get the idea of D, but when I write a







 that others use, they should only see the declaration. How?

 e) compiler enhancement suggestion (see my other thread in the DMC







 the compiler just tells me "function abc(...) does not match argument




 (...)", but it should even tell me which argument it is that does not




 A beginner's problems.... :)

 Christian
Oct 07 2003
parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
MSLU by default is a bad idea. MSLU can cause a lot of headaches.
I would like to have the choice.
-- 
Jan-Eric Duden
"Sarat Venugopal" <sarat_ng n0spam.huelix.com> wrote in message
news:bluanf$1rs$1 digitaldaemon.com...

 What about using MSLU and just forgetting about the ANSI versions?

 Cheers,
 Sarat

 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:blpoiq$1j6i$1 digitaldaemon.com...

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?



 All of the APIS are supported, you might need to wrap them in an extern




 though.


 extern (Windows) {

   private alias long LONG;
   LONG RegQueryValueExA(HKEY, LPCSTR, LPDWORD, LPDWORD, LPBYTE,







   LONG RegOpenKeyExA(HKEY, LPCSTR, DWORD, DWORD, HKEY*);

 }

 Matthew has a registry lib at http://synesis.com.au/synsoft/d.html.

 b) Having no preprocessor is a good idea, but for Windows development







 is a pain



 I dont like #ifdefs and even version statements ( all though the latter







 much prettier! ) , I like to keep two seperate development trees, one







 unicode, one without.


 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use



 Not sure what you mean here, TCHAR is a typedef so its not quite







 either.


 d) When I want to separate the declaration from the definition of a







 how can that be done?



 See matthews registry lib, I havent looked at them but I imagine you can




 something like

 extern (D) {
     // all your functions here

 }

 and then just have them link to your library ... so the implementation







 hidden.


 e) compiler enhancement suggestion (see my other thread in the DMC







 Yea id like this too, but i think Walter is probably unbeleivably
 swamped,Rome wasnt built in a day ( and they had two people! )

 C

 "Christian Kaiser" <chk online.de> wrote in message
 news:blpnm4$1i4s$1 digitaldaemon.com...

 As a first small test, I wanted to port a C++ registry library to D,










 I

 encountered the following problems:

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?

 b) Having no preprocessor is a good idea, but for Windows development







 is a pain. When I want to create a library that can be compiled with










 without using UNICODE, I need to embrace nearly all API calls with the
 "version(UNICODE)", which is unnecessary in C. Unless the Windows API










 defined using all "version()" statements replacing the macros, this










 make conversion and programming Windows applications harder than it







 to

 be. Do I overlook something?

 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use

 version (UNICODE)
 {
 alias wchar syschar;
 }
 else
 {
 alias char syschar;
 }

 but having a standard definition would be better.

 d) When I want to separate the declaration from the definition of a







 how can that be done? class::foo() like in C++ does not compile. I










 that shows that I did not yet get the idea of D, but when I write a







 that others use, they should only see the declaration. How?

 e) compiler enhancement suggestion (see my other thread in the DMC







 the compiler just tells me "function abc(...) does not match argument




 (...)", but it should even tell me which argument it is that does not




 A beginner's problems.... :)

 Christian
Oct 07 2003
parent reply "Sarat Venugopal" <sarat_ng n0spam.huelix.com> writes:
"Jan-Eric Duden" <jeduden whisset.com> wrote in message
news:blufrt$987$1 digitaldaemon.com...

 MSLU by default is a bad idea. MSLU can cause a lot of headaches. I would



              ^^^^^^^^^^^
Would you care to elaborate? Or did Moses say so? <g>  I am not advocating
it, merely suggesting an alternative to maintaining two versions of the
headers. If there are *good reasons* to eliminate it, by all means...

    Win98/ME is fast becoming a history - MSLU provides the best means for a
modern language/framework, FWIW.

Cheers,
Sarat
Oct 07 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
Ughh, all these acronnyms giving me headaches .  MSLU  ?  FWIW ?

C
"Sarat Venugopal" <sarat_ng n0spam.huelix.com> wrote in message
news:blup55$nq3$1 digitaldaemon.com...

 "Jan-Eric Duden" <jeduden whisset.com> wrote in message
 news:blufrt$987$1 digitaldaemon.com...

 MSLU by default is a bad idea. MSLU can cause a lot of headaches. I







 like to have the choice.
               ^^^^^^^^^^^
 Would you care to elaborate? Or did Moses say so? <g>  I am not advocating
 it, merely suggesting an alternative to maintaining two versions of the
 headers. If there are *good reasons* to eliminate it, by all means...

     Win98/ME is fast becoming a history - MSLU provides the best means for




 modern language/framework, FWIW.

 Cheers,
 Sarat
Oct 07 2003
parent "Sarat Venugopal" <sarat_ng n0spam.huelix.com> writes:
MSLU - Microsoft  Layer for Unicode (Enables Unicode APIs in Win98 and ME)
FWIW - For What It's Worth

Cheers,
Sarat

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:blupkp$ofl$1 digitaldaemon.com...

 Ughh, all these acronnyms giving me headaches .  MSLU  ?  FWIW ?

 C
 "Sarat Venugopal" <sarat_ng n0spam.huelix.com> wrote in message
 news:blup55$nq3$1 digitaldaemon.com...

 "Jan-Eric Duden" <jeduden whisset.com> wrote in message
 news:blufrt$987$1 digitaldaemon.com...

 MSLU by default is a bad idea. MSLU can cause a lot of headaches. I







 like to have the choice.
               ^^^^^^^^^^^
 Would you care to elaborate? Or did Moses say so? <g>  I am not







 it, merely suggesting an alternative to maintaining two versions of the
 headers. If there are *good reasons* to eliminate it, by all means...

     Win98/ME is fast becoming a history - MSLU provides the best means







 a

 modern language/framework, FWIW.

 Cheers,
 Sarat
Oct 07 2003
prev sibling parent "Jan-Eric Duden" <jeduden whisset.com> writes:
Here are some issues:

http://www.trigeminal.com/usenet/usenet035.asp?1110011

While working with it, which was version 3xxx :), I had some other bugs,
too.

Furthermore, there are wide-char functions that are not supported by the
MSLU.
For example, all common control functions are not supported, since the
common controls support unicode starting with IE 5.0 ... so all windows 95,
windows 98 systems with ie 4.0 are left out.

Those issues get less and less, but it depends highly on the product how you
want to take care of these problems.
-- 
Jan-Eric Duden
"Sarat Venugopal" <sarat_ng n0spam.huelix.com> wrote in message
news:blup55$nq3$1 digitaldaemon.com...

 "Jan-Eric Duden" <jeduden whisset.com> wrote in message
 news:blufrt$987$1 digitaldaemon.com...

 MSLU by default is a bad idea. MSLU can cause a lot of headaches. I







 like to have the choice.
               ^^^^^^^^^^^
 Would you care to elaborate? Or did Moses say so? <g>  I am not advocating
 it, merely suggesting an alternative to maintaining two versions of the
 headers. If there are *good reasons* to eliminate it, by all means...

     Win98/ME is fast becoming a history - MSLU provides the best means for




 modern language/framework, FWIW.

 Cheers,
 Sarat
Oct 08 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
I just wanted to mention something on the first issue.  D is higher level
than C++ which for me means getting things done quicker, although I often
spend way too much time wrapping windows calls in extern blocks, and trying
to find what library it belongs to.

I'd like to see all the API's wrapped, like instead of having one gigantic
windows.d file, why dont we wrap each of the main libraries functions in a
corresponding file, so to use all the registry functions you would include
advapi32.d etc, and have this included in phobos ( or seperate windows
branch ? I think this is best )

Does anyone want to join me on doing this ?  Or do it all yourself  :) ?

C

"Christian Kaiser" <chk online.de> wrote in message
news:blpnm4$1i4s$1 digitaldaemon.com...

 As a first small test, I wanted to port a C++ registry library to D, and I
 encountered the following problems:

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?

 b) Having no preprocessor is a good idea, but for Windows development this
 is a pain. When I want to create a library that can be compiled with AND
 without using UNICODE, I need to embrace nearly all API calls with the
 "version(UNICODE)", which is unnecessary in C. Unless the Windows API is
 defined using all "version()" statements replacing the macros, this will
 make conversion and programming Windows applications harder than it needs




 be. Do I overlook something?

 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use

 version (UNICODE)
 {
 alias wchar syschar;
 }
 else
 {
 alias char syschar;
 }

 but having a standard definition would be better.

 d) When I want to separate the declaration from the definition of a class,
 how can that be done? class::foo() like in C++ does not compile. I guess
 that shows that I did not yet get the idea of D, but when I write a class
 that others use, they should only see the declaration. How?

 e) compiler enhancement suggestion (see my other thread in the DMC group):
 the compiler just tells me "function abc(...) does not match argument




 (...)", but it should even tell me which argument it is that does not




 A beginner's problems.... :)

 Christian
Oct 05 2003
next sibling parent reply "Christian Kaiser" <chk online.de> writes:
BTW: Charles, you should change your signature to "D" :)


 C
Oct 05 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Hehe, most of my friends call me Chuck D so i just might!

D
"Christian Kaiser" <chk online.de> wrote in message
news:blpqis$1lug$1 digitaldaemon.com...

 BTW: Charles, you should change your signature to "D" :)


 C
Oct 05 2003
prev sibling next sibling parent reply "Christian Kaiser" <chk online.de> writes:
Sounds good (just like the header files in C/C++) <grin>

You're right, it should be separated. But another aspect comes to my mind
here you should take care of: version dependency. Most DLLs get new APIs,
structs (and/or modifications of the old ones) and constants in a newer
version, so there must be something like the #define WINVER that an
application programmer can define so that the declaration files only include
APIs that are existent in that Windows version. Does the "version()" have
the ability to check for "greater than", that is "version (Windows >=
0x400)"...

Else start creating different declaration files, and use "imports win32.400"
or the like. But if you need to be flexible and support multiple versions
(OPENFILENAME for example), you're back to writing them yourself.

Sigh. It's all a mess (or a big heap of work, unless a header file
translator is being done). Given the speed MS issues new APIs and
interfaces, there's no other way than to automize that. Or to allow the D
compiler to read C header files (including all that preprocessor stuff) and
be compatible with the MS headers, including all the XP tricks they use in
the headers, including also inline asm.

Christian

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:blpp9c$1k38$1 digitaldaemon.com...

 I just wanted to mention something on the first issue.  D is higher level
 than C++ which for me means getting things done quicker, although I often
 spend way too much time wrapping windows calls in extern blocks, and




 to find what library it belongs to.

 I'd like to see all the API's wrapped, like instead of having one gigantic
 windows.d file, why dont we wrap each of the main libraries functions in a
 corresponding file, so to use all the registry functions you would include
 advapi32.d etc, and have this included in phobos ( or seperate windows
 branch ? I think this is best )

 Does anyone want to join me on doing this ?  Or do it all yourself  :) ?

 C

 "Christian Kaiser" <chk online.de> wrote in message
 news:blpnm4$1i4s$1 digitaldaemon.com...

 As a first small test, I wanted to port a C++ registry library to D, and







 encountered the following problems:

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?

 b) Having no preprocessor is a good idea, but for Windows development







 is a pain. When I want to create a library that can be compiled with AND
 without using UNICODE, I need to embrace nearly all API calls with the
 "version(UNICODE)", which is unnecessary in C. Unless the Windows API is
 defined using all "version()" statements replacing the macros, this will
 make conversion and programming Windows applications harder than it







 to

 be. Do I overlook something?

 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use

 version (UNICODE)
 {
 alias wchar syschar;
 }
 else
 {
 alias char syschar;
 }

 but having a standard definition would be better.

 d) When I want to separate the declaration from the definition of a







 how can that be done? class::foo() like in C++ does not compile. I guess
 that shows that I did not yet get the idea of D, but when I write a







 that others use, they should only see the declaration. How?

 e) compiler enhancement suggestion (see my other thread in the DMC







 the compiler just tells me "function abc(...) does not match argument




 (...)", but it should even tell me which argument it is that does not




 A beginner's problems.... :)

 Christian
Oct 05 2003
parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
 You're right, it should be separated. But another aspect comes to my mind
 here you should take care of: version dependency



Good point, yea you can use the command line to do version=2 (or similar )
which will compile everything up to version 2.


 Sigh. It's all a mess (or a big heap of work, unless a header file
 translator is being done).



Yea its a lot of work, but not as much as I expected, generally write the
correct aliases, strip the #preproccess and wrap in extern (Windows ), I've
only done this once though so I dont have much experience in it.

There's also SWIG which will create D from C / C++.   I tried it on a pretty
complex header and got some mixed results, im not sure im using it right but
you might want to give it a try

http://www.digitalmars.com/d/dlinks.html.

Heres a short list stolen from MSVC

C:\WINNT\System32\ntdll.dll
C:\WINNT\system32\ws2_32.dll
C:\WINNT\system32\msvcrt.dll
C:\WINNT\system32\KERNEL32.DLL
C:\WINNT\system32\ADVAPI32.DLL
C:\WINNT\system32\rpcrt4.dll
C:\WINNT\system32\ws2help.dll
C:\WINNT\system32\winmm.dll
C:\WINNT\system32\USER32.DLL
C:\WINNT\system32\GDI32.DLL
C:\WINNT\system32\COMDLG32.DLL
C:\WINNT\system32\SHLWAPI.DLL
C:\WINNT\system32\comctl32.dll
C:\WINNT\system32\SHELL32.DLL
C:\WINNT\system32\WINSPOOL.DRV
C:\WINNT\system32\mpr.dll
C:\WINNT\system32\oledlg.dll
C:\WINNT\system32\OLE32.DLL
C:\WINNT\system32\OLEPRO32.DLL
C:\WINNT\system32\OLEAUT32.DLL
C:\WINNT\system32\mmdrv.dll

I'll try to use SWIG on these headers (the ones that arent already
wrapped ), im going to start with the ones in caps.  Help is welcome! :)

"Christian Kaiser" <chk online.de> wrote in message
news:blprb9$1mu7$1 digitaldaemon.com...

 Sounds good (just like the header files in C/C++) <grin>

 You're right, it should be separated. But another aspect comes to my mind
 here you should take care of: version dependency. Most DLLs get new APIs,
 structs (and/or modifications of the old ones) and constants in a newer
 version, so there must be something like the #define WINVER that an
 application programmer can define so that the declaration files only




 APIs that are existent in that Windows version. Does the "version()" have
 the ability to check for "greater than", that is "version (Windows >=
 0x400)"...

 Else start creating different declaration files, and use "imports




 or the like. But if you need to be flexible and support multiple versions
 (OPENFILENAME for example), you're back to writing them yourself.

 Sigh. It's all a mess (or a big heap of work, unless a header file
 translator is being done). Given the speed MS issues new APIs and
 interfaces, there's no other way than to automize that. Or to allow the D
 compiler to read C header files (including all that preprocessor stuff)




 be compatible with the MS headers, including all the XP tricks they use in
 the headers, including also inline asm.

 Christian

 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:blpp9c$1k38$1 digitaldaemon.com...

 I just wanted to mention something on the first issue.  D is higher







 than C++ which for me means getting things done quicker, although I







 spend way too much time wrapping windows calls in extern blocks, and




 to find what library it belongs to.

 I'd like to see all the API's wrapped, like instead of having one







 windows.d file, why dont we wrap each of the main libraries functions in







 corresponding file, so to use all the registry functions you would







 advapi32.d etc, and have this included in phobos ( or seperate windows
 branch ? I think this is best )

 Does anyone want to join me on doing this ?  Or do it all yourself  :) ?

 C

 "Christian Kaiser" <chk online.de> wrote in message
 news:blpnm4$1i4s$1 digitaldaemon.com...

 As a first small test, I wanted to port a C++ registry library to D,










 I

 encountered the following problems:

 a) I did not find any mention which Windows APIs are supported - for
 example, RegOpenKeyExA() isn't. Where can such a list be found?

 b) Having no preprocessor is a good idea, but for Windows development







 is a pain. When I want to create a library that can be compiled with










 without using UNICODE, I need to embrace nearly all API calls with the
 "version(UNICODE)", which is unnecessary in C. Unless the Windows API










 defined using all "version()" statements replacing the macros, this










 make conversion and programming Windows applications harder than it







 to

 be. Do I overlook something?

 c) I would like to have a standardized char format for that purpose as




 is for Windows. At the moment, I use

 version (UNICODE)
 {
 alias wchar syschar;
 }
 else
 {
 alias char syschar;
 }

 but having a standard definition would be better.

 d) When I want to separate the declaration from the definition of a







 how can that be done? class::foo() like in C++ does not compile. I










 that shows that I did not yet get the idea of D, but when I write a







 that others use, they should only see the declaration. How?

 e) compiler enhancement suggestion (see my other thread in the DMC







 the compiler just tells me "function abc(...) does not match argument




 (...)", but it should even tell me which argument it is that does not




 A beginner's problems.... :)

 Christian
Oct 05 2003
parent reply "Y.Tomino" <demoonlit inter7.jp> writes:
Hello.


I'll try to use SWIG on these headers (the ones that arent already
wrapped ), im going to start with the ones in caps.  Help is welcome! :)



I'm trying with Perl.
http://hp.vector.co.jp/authors/VA028375/contents/D_windows.h.html
(Sorry, this is Japanease.)

I hope you find it informative.
(and I hope change "import windows.d;" in Phobos to "private import
windows.d;" to avoid conflicting identifiers.)

YT
Oct 06 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Yes, that makes it hard for us to replace windows.d.  What I've been doing
is overwriting Phobos's worse-than-useless windows.d with my own or Pavel's.

I don't know Perl.  My attempts so far have been hand translation of just
the parts that I considered necessary to get my program to run.  I keep
thinking somebody somewhere will do the job right, and we can all just use
that.  ;)

Sean

"Y.Tomino" <demoonlit inter7.jp> wrote in message
news:blrkbh$180j$1 digitaldaemon.com...

 Hello.


I'll try to use SWIG on these headers (the ones that arent already
wrapped ), im going to start with the ones in caps.  Help is welcome! :)



 I'm trying with Perl.
 http://hp.vector.co.jp/authors/VA028375/contents/D_windows.h.html
 (Sorry, this is Japanease.)

 I hope you find it informative.
 (and I hope change "import windows.d;" in Phobos to "private import
 windows.d;" to avoid conflicting identifiers.)

 YT
Oct 06 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
Awesome!  I wish I knew japanese their seem to be a great number of
resources.  Do you mind if I bundle this with DIDE ?  Ill include pavel's
winsock modules also, and write some docs for all of it.


Thanks,
C

"Y.Tomino" <demoonlit inter7.jp> wrote in message
news:blrkbh$180j$1 digitaldaemon.com...

 Hello.


I'll try to use SWIG on these headers (the ones that arent already
wrapped ), im going to start with the ones in caps.  Help is welcome! :)



 I'm trying with Perl.
 http://hp.vector.co.jp/authors/VA028375/contents/D_windows.h.html
 (Sorry, this is Japanease.)

 I hope you find it informative.
 (and I hope change "import windows.d;" in Phobos to "private import
 windows.d;" to avoid conflicting identifiers.)

 YT
Oct 06 2003
parent "Y.Tomino" <demoonlit inter7.jp> writes:
Do you mind if I bundle this with DIDE ?




However, I'm interested in SWIG, too. 
Please do your best.

YT
Oct 07 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:blpp9c$1k38$1 digitaldaemon.com...

 I just wanted to mention something on the first issue.  D is higher level
 than C++ which for me means getting things done quicker, although I often
 spend way too much time wrapping windows calls in extern blocks, and




 to find what library it belongs to.

 I'd like to see all the API's wrapped, like instead of having one gigantic
 windows.d file, why dont we wrap each of the main libraries functions in a
 corresponding file, so to use all the registry functions you would include
 advapi32.d etc, and have this included in phobos ( or seperate windows
 branch ? I think this is best )

 Does anyone want to join me on doing this ?  Or do it all yourself  :) ?



I think one per-dll would be too large. I am, however, very keen on the idea
of a per-API module. I've pretty much done this within the internals for the
registry lib, including the specific as typedef, and not alias, the HKEY
type.
Oct 07 2003