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
>

"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  :) ?

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.

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

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

>Do you mind if I bundle this with DIDE ?
I don't mind.

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

YT

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

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

"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
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 a
modern language/framework, FWIW.

Cheers,
Sarat

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
would
> 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
a
> modern language/framework, FWIW.
>
> Cheers,
> Sarat
>
>

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
> would
> > 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
> a
> > modern language/framework, FWIW.
> >
> > Cheers,
> > Sarat
> >
> >
>
>

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
would
> 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
a
> modern language/framework, FWIW.
>
> Cheers,
> Sarat
>
>