www.digitalmars.com         C & C++   DMDScript  

D - D + Win32 strategy?

reply "Luna Kid" <lunakid neuropolis.org> writes:
Starting my very first Win32 app in D, I wanted to ask Walter
in private:

    "Could you please add

        HDC GetDC(HWND hWnd);

    to phobos/windows.d (around line 1184)?"

but I soon realized there are many other crucial omissions yet.

- What is the current best practical approach to develop
  Win32 stuff in D (preferably without learning extra
  frameworks like DIG)?

- What is the strategy of extending windows.d into a full
  Win32 interface? (Asking this because bugging Walter with
  "please add this and that" may not be a viable solution...)

Thanks,
Sz.
(If the above sounds ridiculously clueless it is because
I _am_ ridiculously clueless...)
May 14 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Luna Kid" <lunakid neuropolis.org> wrote in message
news:b9tob6$1jm7$1 digitaldaemon.com...

 Starting my very first Win32 app in D, I wanted to ask Walter
 in private:

     "Could you please add

         HDC GetDC(HWND hWnd);

     to phobos/windows.d (around line 1184)?"


Ok.


 - What is the current best practical approach to develop
   Win32 stuff in D (preferably without learning extra
   frameworks like DIG)?


Do it just like you would in C++ or C (except don't use MFC).


 - What is the strategy of extending windows.d into a full
   Win32 interface? (Asking this because bugging Walter with
   "please add this and that" may not be a viable solution...)


Just add anything missing as needed.
May 14 2003
parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <b9u0tu$1tv6$1 digitaldaemon.com>, Walter says...


 - What is the strategy of extending windows.d into a full
   Win32 interface? (Asking this because bugging Walter with
   "please add this and that" may not be a viable solution...)


Just add anything missing as needed.


I was wondering if we could use the wiki as a collaborative windows.d
editing project?  If everyone was conscientious about it every time 
you added a delaration to your own local windows.d file you could check 
the wiki and add it to the windows.d page if it did not exist.  Then you 
could also periodically cut and paste the code to you own local file to 
get everyone elses changes.
May 14 2003
next sibling parent reply Bill Cox <bill viasic.com> writes:
Hi.

I like the idea of a Wiki, although a SourceForge project might be 
better.  However, I'm not very excited about the thought of programming 
directly to the win32 api.  MFC is so much more productive, especially 
with ClassWizard.

OTOH, developing a good GUI interface library for D from scratch is an 
enourmous task.

Is there any other way?  Are there any good share-ware GUI libs out 
there we could write wrappers for?  That could help in porting GUIs to 
Linux, which is currently a nightmare.

We currently write our GUIs twice: once for Windows and once for Linux. 
  he MainSoft stuff for porting to Linux makes for bad Linux interfaces. 
  Running GTK+ on Windows isn't yet stable enough, and may make a bad 
Windows interface.  An alternative is Java, which is nice, but then 
we've got debugging and installation headaches.

Bill

Patrick Down wrote:

 In article <b9u0tu$1tv6$1 digitaldaemon.com>, Walter says...
 
 

- What is the strategy of extending windows.d into a full
  Win32 interface? (Asking this because bugging Walter with
  "please add this and that" may not be a viable solution...)


Just add anything missing as needed.


 
 
 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time 
 you added a delaration to your own local windows.d file you could check 
 the wiki and add it to the windows.d page if it did not exist.  Then you 
 could also periodically cut and paste the code to you own local file to 
 get everyone elses changes.
May 14 2003
parent reply Ilya Minkov <Ilya_member pathlink.com> writes:
In article <3EC2ABA2.3060208 viasic.com>, Bill Cox says...

Hi.

I like the idea of a Wiki, although a SourceForge project might be 
better.  However, I'm not very excited about the thought of programming 
directly to the win32 api.  MFC is so much more productive, especially 
with ClassWizard.


A SourceForge project is PITA, because:
- it requieres everyone to have CVS clients installed;
- syncronisation is a problem, because one has to pray that noone has done a
post just before himself;
- there are people who have no experiance with CVS including myself. So please
correct me where appropriate.


OTOH, developing a good GUI interface library for D from scratch is an 
enourmous task.


However, a full API translation would be desirable anyway, right?
BTW, i have to actually start writing the damn tool. :>


Is there any other way?  Are there any good share-ware GUI libs out 
there we could write wrappers for?  That could help in porting GUIs to 
Linux, which is currently a nightmare.

We currently write our GUIs twice: once for Windows and once for Linux. 
  he MainSoft stuff for porting to Linux makes for bad Linux interfaces. 
  Running GTK+ on Windows isn't yet stable enough, and may make a bad 
Windows interface.  An alternative is Java, which is nice, but then 
we've got debugging and installation headaches.


There are following alternatives:

== GUI native wrappers ==

* TK (known as TCL/TK) - accesible from C. - good for simple interfaces.

* wxWindows - a C++ library, fairly powerful but somewhat inconsistent across
platforms (Win32, GTK+, MacOS-X). I guess a C wrapper exists. The library relies
on inheritance as opposed to callback functions. I'm not sure how well these
things can be ported to D.

Another whole class are client-draw libraries - like FLTK, Qt, FOX, Amulet and
others. They simply wrap OSes primitive drawing capabilities and use them to
draw in a platform-independant manner. The ones named here are C++. It doesn't
seem to make much sense to wrap these - apart from Qt on Unix only. However,
some of these may be taken as a basis to write a clent-draw library for D.
Amulet, e.g., shows some unique features.

I think a skinnable clientdraw library based on SDL (directdraw-like interface)
might make sense. I was considering writing one like that in Sather.
Skinnability would allow to adjust it to a specific platform's look and feel.
There has already been a working application written this way - Pixel32, a
Photoshop clone, done in FreePascal using LibSDL. And i guess OpenOffice and
Mozilla use a kind of a similar concept.

http://pixel32.box.sk/

And finally, there are people who think that all this platform-independance is
crap, and no wrapper may ever cover everything - and they may be right. The core
of an application is platform-independant, and cooperates through a well-defined
interface with a platform-dependant part. The overal result may be very
impressive. Look at this and read their publications:

http://www.abisource.com/

-i.
May 15 2003
parent Bill Cox <bill viasic.com> writes:
Hi, Ilya.

Ilya Minkov wrote:

 In article <3EC2ABA2.3060208 viasic.com>, Bill Cox says...
 

Hi.

I like the idea of a Wiki, although a SourceForge project might be 
better.  However, I'm not very excited about the thought of programming 
directly to the win32 api.  MFC is so much more productive, especially 
with ClassWizard.


 
 
 A SourceForge project is PITA, because:
 - it requieres everyone to have CVS clients installed;
 - syncronisation is a problem, because one has to pray that noone has done a
 post just before himself;
 - there are people who have no experiance with CVS including myself. So please
 correct me where appropriate.


CVS deals with the syncronisation problems mostly automatically.  It 
does a three-way merge, which means it knows what version you started 
with, what changes have been made since then by others, and what changes 
you've made.  It combines all changes that don't overlap.  It sounds 
scary, but it actually works really well.

I think I understand why many people haven't dealt with CVS: lots of 
programmers work alone.  CVS is mostly for teams of programmers.

I'd strongly recomend that anyone wanting to work with other programmers 
install and learn CVS.  It's well worth the effort.  There's a good 
Windows client that comes with the Cygwin install from RedHat.  I also 
recomend that programmers working on Windows install Cygwin.  It's a 
good productivity tool for most programmers who use it, and it's fairly 
easy to install.  Here's a link:

http://sources.redhat.com/cygwin/


OTOH, developing a good GUI interface library for D from scratch is an 
enourmous task.


 
 
 However, a full API translation would be desirable anyway, right?
 BTW, i have to actually start writing the damn tool. :>
 

Is there any other way?  Are there any good share-ware GUI libs out 
there we could write wrappers for?  That could help in porting GUIs to 
Linux, which is currently a nightmare.

We currently write our GUIs twice: once for Windows and once for Linux. 
 he MainSoft stuff for porting to Linux makes for bad Linux interfaces. 
 Running GTK+ on Windows isn't yet stable enough, and may make a bad 
Windows interface.  An alternative is Java, which is nice, but then 
we've got debugging and installation headaches.


 
 
 There are following alternatives:
 
 == GUI native wrappers ==
 
 * TK (known as TCL/TK) - accesible from C. - good for simple interfaces.
 
 * wxWindows - a C++ library, fairly powerful but somewhat inconsistent across
 platforms (Win32, GTK+, MacOS-X). I guess a C wrapper exists. The library
relies
 on inheritance as opposed to callback functions. I'm not sure how well these
 things can be ported to D.
 
 Another whole class are client-draw libraries - like FLTK, Qt, FOX, Amulet and
 others. They simply wrap OSes primitive drawing capabilities and use them to
 draw in a platform-independant manner. The ones named here are C++. It doesn't
 seem to make much sense to wrap these - apart from Qt on Unix only. However,
 some of these may be taken as a basis to write a clent-draw library for D.
 Amulet, e.g., shows some unique features.
 
 I think a skinnable clientdraw library based on SDL (directdraw-like interface)
 might make sense. I was considering writing one like that in Sather.
 Skinnability would allow to adjust it to a specific platform's look and feel.
 There has already been a working application written this way - Pixel32, a
 Photoshop clone, done in FreePascal using LibSDL. And i guess OpenOffice and
 Mozilla use a kind of a similar concept.
 
 http://pixel32.box.sk/


A skinnable GUI sounds pretty cool...  it might have lots of uses like 
porting to multiple platforms, or having custom skins optimized for PDAs 
or cell phones.  The lack of built-in GUI in HTML has driven people to 
make custom bitmaps for their stuff, and it looks very cool.


 And finally, there are people who think that all this platform-independance is
 crap, and no wrapper may ever cover everything - and they may be right. The
core
 of an application is platform-independant, and cooperates through a
well-defined
 interface with a platform-dependant part. The overal result may be very
 impressive. Look at this and read their publications:
 
 http://www.abisource.com/


This is basically what we do now.  We haven't set it up yet, but we plan 
to have our GUIs comunicate with our EDA tools through TCL commands, 
with no calls directly to the tools.  It's a nice way to go, but you 
wind up having to hire at least one GUI expert for each platform, and 
the GUIs are always somewhat out of sync.

I guess I'd prefer a skinnable GUI library, but frankly, I'm not a very 
good GUI programmer, so I doubt I'd do anyone much good by contributing 
to such an effort.

Bill
May 15 2003
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Patrick Down wrote:

 In article <b9u0tu$1tv6$1 digitaldaemon.com>, Walter says...
 
 

- What is the strategy of extending windows.d into a full
  Win32 interface? (Asking this because bugging Walter with
  "please add this and that" may not be a viable solution...)


Just add anything missing as needed.


 
 
 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time 
 you added a delaration to your own local windows.d file you could check 
 the wiki and add it to the windows.d page if it did not exist.  Then you 
 could also periodically cut and paste the code to you own local file to 
 get everyone elses changes.


I've noticed that many useful Win32 constants, types, and prototypes 
aren't included in Phobos's windows.d.  Somehow I think we should have a 
unified effort to either add these to windows.d (if Walter is willing), 
or develop supplemental headers that work in friendly fashion with 
Phobos.  A wiki could be a good way to do a collaborative project.

I've come up with 3400+ lines of Win32 symbols that aren't in windows.d 
(maybe some of them should be).  If you want to use it, just add "import 
win.d;" in your import section.

You can download my file at:
http://www.geocities.com/jccalvarese/d/win.zip

I'm sure my header isn't perfect.  It's not particularly organized.  It 
may still include conflicts with Phobos.  (I've removed conflicts as 
I've found them, but they can be hidden.)  If you find any problems with 
it, let me know and I can try to fix it.

Justin
May 14 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
It would be really nice if this project was completed and included in the
compiler distribution as soon as possible.  I myself have added hundreds if
not more lines from windows.h and kin just to get small demos up and
running.  Quite the PITA.  Plus the variants seem to be prolifigating.  It
would be wise to nip this in the bud.

Not to mention recently introduced incompatibilities so that older ones like
Pavel's have problems compiling with the newer DMD variants.  And Pavel is
not around apparently to fix it, or no longer cares.

Sean

"J C Calvarese" <jcc7 cox.net> wrote in message
news:b9ubk3$2a08$1 digitaldaemon.com...

 Patrick Down wrote:

 In article <b9u0tu$1tv6$1 digitaldaemon.com>, Walter says...



- What is the strategy of extending windows.d into a full
  Win32 interface? (Asking this because bugging Walter with
  "please add this and that" may not be a viable solution...)


Just add anything missing as needed.



 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then you
 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


 I've noticed that many useful Win32 constants, types, and prototypes
 aren't included in Phobos's windows.d.  Somehow I think we should have a
 unified effort to either add these to windows.d (if Walter is willing),
 or develop supplemental headers that work in friendly fashion with
 Phobos.  A wiki could be a good way to do a collaborative project.

 I've come up with 3400+ lines of Win32 symbols that aren't in windows.d
 (maybe some of them should be).  If you want to use it, just add "import
 win.d;" in your import section.

 You can download my file at:
 http://www.geocities.com/jccalvarese/d/win.zip

 I'm sure my header isn't perfect.  It's not particularly organized.  It
 may still include conflicts with Phobos.  (I've removed conflicts as
 I've found them, but they can be hidden.)  If you find any problems with
 it, let me know and I can try to fix it.

 Justin
May 14 2003
prev sibling parent reply "Brad Anderson" <bsa sankaty.com> writes:
I know this doesn't help the discussion in this thread, but I've made some
changes to get a program working.  Since there is no forum or wiki yet, I
wanted to let Walter and Justin know about these changes to win.d and
windows.d, and let them discard or accept as they see fit.

I needed to set the current directory (SetCurrentDirectory) as well as loop
thru files (FindFirstFile, FindNextFile) in that directory.  So, my
additions are the following:

-----
windows.d (around line 260, 5/15/2003 version)

alias FindFirstFileA FindFirstFile;
alias FindNextFileA FindNextFile;

-----
win.d (5/14/2003 version)
 - rem'd out 2675 thru 2689 (the struct WIN32_FIND_DATA and aliases)
 - rem'd out 3264 thru 3274
 - rem'd out 3292 thru 3295

 - at end:

/+  -------------------------------------------
 +  from winbase.h
 + -------------------------------------------
 +/

alias SetCurrentDirectoryA SetCurrentDirectory;

extern(Windows)
{
 export
 {

  BOOL SetCurrentDirectoryA(LPCSTR);
  BOOL SetCurrentDirectoryW(LPCWSTR);
 }
}

I am a newbie to D, and hope that I made the right changes to expose these
methods to my D app.  In any case, the app works great, and is
mind-bogglingly fast.  Any feedback on what I did is welcome.

Cheers,
Brad







"J C Calvarese" <jcc7 cox.net> wrote in message
news:b9ubk3$2a08$1 digitaldaemon.com...

 Patrick Down wrote:

 In article <b9u0tu$1tv6$1 digitaldaemon.com>, Walter says...



- What is the strategy of extending windows.d into a full
  Win32 interface? (Asking this because bugging Walter with
  "please add this and that" may not be a viable solution...)


Just add anything missing as needed.



 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then you





 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


 I've noticed that many useful Win32 constants, types, and prototypes
 aren't included in Phobos's windows.d.  Somehow I think we should have a
 unified effort to either add these to windows.d (if Walter is willing),
 or develop supplemental headers that work in friendly fashion with
 Phobos.  A wiki could be a good way to do a collaborative project.

 I've come up with 3400+ lines of Win32 symbols that aren't in windows.d
 (maybe some of them should be).  If you want to use it, just add "import
 win.d;" in your import section.

 You can download my file at:
 http://www.geocities.com/jccalvarese/d/win.zip

 I'm sure my header isn't perfect.  It's not particularly organized.  It
 may still include conflicts with Phobos.  (I've removed conflicts as
 I've found them, but they can be hidden.)  If you find any problems with
 it, let me know and I can try to fix it.

 Justin
May 20 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Brad,

Thanks for pointing out the conflicts (oops).  I removed the extra code 
from win.d.  My line numbers don't seem to  match up with yours--maybe I 
made some cosmetic changes after I uploaded it.  I also cleaned up some 
code all over the place.  (I think every time I used "bit" I meant 
"BOOL".)

I think that the lines you suggested adding to windows.d would work just 
as well in win.d for the time being, so I hope you won't be offended 
that I've left my alias's to Find*File in there.  My current strategy is 
to keep track of the stuff that'd be nice to put in windows.d in win.d. 
  That way when I install a new release of DMD, I don't lose the changes 
I made to windows.d.  Now if Walter adds some of this stuff to 
windows.d, of course I'll remove those items from win.d.

Same download URL, new file: http://www.geocities.com/jccalvarese/d/win.zip

Justin

Brad Anderson wrote:

 I know this doesn't help the discussion in this thread, but I've made some
 changes to get a program working.  Since there is no forum or wiki yet, I
 wanted to let Walter and Justin know about these changes to win.d and
 windows.d, and let them discard or accept as they see fit.
 
 I needed to set the current directory (SetCurrentDirectory) as well as loop
 thru files (FindFirstFile, FindNextFile) in that directory.  So, my
 additions are the following:
 
 -----
 windows.d (around line 260, 5/15/2003 version)
 
 alias FindFirstFileA FindFirstFile;
 alias FindNextFileA FindNextFile;
 
 -----
 win.d (5/14/2003 version)
  - rem'd out 2675 thru 2689 (the struct WIN32_FIND_DATA and aliases)
  - rem'd out 3264 thru 3274
  - rem'd out 3292 thru 3295
 
  - at end:
 
 /+  -------------------------------------------
  +  from winbase.h
  + -------------------------------------------
  +/
 
 alias SetCurrentDirectoryA SetCurrentDirectory;
 
 extern(Windows)
 {
  export
  {
 
   BOOL SetCurrentDirectoryA(LPCSTR);
   BOOL SetCurrentDirectoryW(LPCWSTR);
  }
 }
 
 I am a newbie to D, and hope that I made the right changes to expose these
 methods to my D app.  In any case, the app works great, and is
 mind-bogglingly fast.  Any feedback on what I did is welcome.
 
 Cheers,
 Brad
May 21 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
 code all over the place.  (I think every time I used "bit" I meant
 "BOOL".)


Ehh, I wish D would make such additional comments
unnecessary... ;)

Cheers,
Sz.
May 22 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:b9u622$23pe$1 digitaldaemon.com...

 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then you
 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


Sounds like a good idea. Just be careful not to violate Microsoft's
copyrights on it.
May 14 2003
next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in news:b9v4em$um$1
 digitaldaemon.com:


 
 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:b9u622$23pe$1 digitaldaemon.com...

 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then you
 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


 
 Sounds like a good idea. Just be careful not to violate Microsoft's
 copyrights on it.


Yes this is one of the things I was worried about and I'm no expert on
the legal issues.  Does any one know anything about this?
May 15 2003
parent "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns937C5530F801Bpatcodemooncom 63.105.9.61...

 "Walter" <walter digitalmars.com> wrote in news:b9v4em$um$1
  digitaldaemon.com:

 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:b9u622$23pe$1 digitaldaemon.com...

 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then






you

 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


 Sounds like a good idea. Just be careful not to violate Microsoft's
 copyrights on it.


 Yes this is one of the things I was worried about and I'm no expert on
 the legal issues.  Does any one know anything about this?


I'm not a lawyer, either, but I think you're clear if you rewrite the api in
your own words. If you copy Microsoft's comments, etc., I think that's a
violation. If somebody has done a GPL'd windows.h, you can modify that one.

BTW, Microsoft was kind enough to grant a license to Digital Mars to use the
Microsoft .h files.
May 18 2003
prev sibling parent MarkT <MarkT_member pathlink.com> writes:
 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then you
 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


Sounds like a good idea. Just be careful not to violate Microsoft's
copyrights on it.


they could get the information from the Wine project http://www.winehq.com/
May 16 2003
prev sibling next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
Patrick Down wrote:

 
 In article <b9u0tu$1tv6$1 digitaldaemon.com>, Walter says...
 

 - What is the strategy of extending windows.d into a full
   Win32 interface? (Asking this because bugging Walter with
   "please add this and that" may not be a viable solution...)


Just add anything missing as needed.


 
 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?  If everyone was conscientious about it every time
 you added a delaration to your own local windows.d file you could check
 the wiki and add it to the windows.d page if it did not exist.  Then you
 could also periodically cut and paste the code to you own local file to
 get everyone elses changes.


I'm a wiki enthusiast and really won't mind if someone tried to do this
using a wiki page e. g. in Wiki4D ( http://www.prowiki.org/wiki4d/wiki.cgi ).

But I have some doubts, because I think that
  - CVS is the tool for that task
  - the 400+ KB of the windows.d file are a PITA to handle in a wiki page

If someone really want to do it, I think I would have to support it in
some kind of sections that can be easily edited and are integrated to
the complete file when downloaded. Should be no problem, but has never
been done, as far as I know.

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 19 2003
prev sibling parent =?iso-8859-15?Q?=22Robert_M._M=FCnch=22?= <robert.muench robertmuench.de> writes:
Am Wed, 14 May 2003 19:39:46 +0000 (UTC) hat Patrick Down 
<Patrick_member pathlink.com> geschrieben:


 I was wondering if we could use the wiki as a collaborative windows.d
 editing project?


Hi, I don't want to start big discussions about the best way to go but 
please have a look at http://www.xpeers.net (Attention CSS2 used :-|), 
which is a P2P collaboration platform I'm involved in.

I'm running a demo-server and could give people access to this platform. 
With this it's quite easy to keep one version in sync without a big 
infrastructure setup. We could than automatically update new versions for 
download as well.

Just an offer to the community. Anyone interested?

--
Robert M. Münch
IT & Management Freelancer
http://www.robertmuench.de
May 30 2003