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

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

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

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
call
> 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
> TCHAR
> > is for Windows. At the moment, I use
>
> Not sure what you mean here, TCHAR is a typedef so its not quite standard
either.

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

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

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

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

> C

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

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

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

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

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