• Ant (15/35) Nov 21 2004 John Reimer found that
• Ant (14/14) Nov 21 2004 ignore this I think I got it.
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (8/15) Nov 21 2004 No, that is wrong.
• Ant (4/13) Nov 21 2004 thank you.
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (6/9) Nov 22 2004 Since it currently has "Win32" and "linux" hardcoded,
• Ant (5/14) Nov 22 2004 My fault! :(
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (7/15) Nov 23 2004 Yes, you could start by doing that and any real linux
• Ant (4/5) Nov 23 2004 I don't think I have the time or the will to learn how to use it.
• Ant (4/8) Nov 22 2004 thank you, I didn't notice that until now.
• h3r3tic (3/4) Nov 21 2004 I don't think this is a problem to anyone. D needs a good GUI and DUI
• Regan Heath (14/18) Nov 21 2004 Not a problem, however it might be 'nicer' if you had your own group, li...
• John Reime (11/23) Nov 21 2004 I like that idea... GUI programming discussions would likely be popular ...
• Simon Buchan (7/11) Nov 22 2004 Well I dont know if a gui group would get enough traffic for a while (I ...
• Ant (27/27) Nov 22 2004 ok, here is what I have:
• John Reimer (27/54) Nov 23 2004 Ant,
• Ant (3/8) Nov 23 2004 thank you, I'll try that later tonight.
• Ant (9/20) Nov 23 2004 seems that doesn't work with link.exe.
• John Reimer (13/33) Nov 23 2004 Sorry, Ant,
• Ant (10/13) Nov 23 2004 hey, thank you for your help, no need for appologises!
• Ant (12/14) Nov 23 2004 (I mean the windows version, the linux version has it since I can rememb...
• John Reimer (4/8) Nov 23 2004 Your welcome! Glad I could help!
• John Reimer (3/30) Nov 23 2004 And just to clarify, I have succeeded in getting DUI's opengl working w...
• Walter (5/9) Nov 23 2004 Hmm. This sounds like it could be the cause of the crashing problem you ...

Ant <duitoolkit yahoo.ca> writes:

John Reimer found that

replacing extern(C) with extern(Windows) on the
DUI OpenGL extension decalrations fixes all the problems
with the OpenGL on DUI.

how do I know which to one use?

DUI is a wrapper to Gtk+ DLLs
DUI openGL is a wrapper to GtkGlExt DLLs.

The interface with the system opengl libs is made through
GtkGLExt.

Why should I use extern(C) for Gtk+
and extern(Windows) for GtkGlExt ?
how do I know which to one use?

Ant

from a discussion with John:
 --- John Reimer wrote: 
 Ant wrote:
 
 --- John Reimer wrote: 
  
You think I'll have to change all extern(C) to extern(Windows)
or just the OpenGL one?

go to any class on DUI and there is extern(C)...

funny, I believe I try that a year ago, I'm pretty sure I did...

Ant


 Just opengl ones... because they are part of the win32 system.  GTK

 is a 
 just a standard C library, not a system library (as far as I
 understand 
 it), so it doesn't have much to do with WINAPI calls.
 

Ant <duitoolkit yahoo.ca> writes:

ignore this I think I got it.
calls to gl* function go directly to the system libraries
the GtkGlExt just enables that (somehow).

now, to use extern(C) and extern(Windows)... how is it?

version(Win32) extern(Windows):
version(linux) extern(C):
glFunctions...
glFunctions...
glFunctions...
glFunctions...
glFunctions...

will it work? I'll give it a try.

Ant

PS sorry for sequestring the D group for DUI...

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ant wrote:

 now, to use extern(C) and extern(Windows)... how is it?
 
 version(Win32) extern(Windows):
 version(linux) extern(C):
 glFunctions...
 
 will it work? I'll give it a try.

No, that is wrong.
You want to write:

version(Win32) extern(Windows):
else           extern(C):

Since there are other platforms.
Remember: Not Windows != Linux.

--anders

Ant <duitoolkit yahoo.ca> writes:

Anders F Björklund wrote:
 
 No, that is wrong.
 You want to write:
 
 version(Win32) extern(Windows):
 else           extern(C):
 
 Since there are other platforms.
 Remember: Not Windows != Linux.

thank you.

any reports of DUI working on other platforms are welcome!

Ant

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ant wrote:

 thank you.
 
 any reports of DUI working on other platforms are welcome!

Since it currently has "Win32" and "linux" hardcoded,
it won't compile on platforms other than those two...

Neither dool nor DUI compiles.
(bug reports on SourceForge)

--anders

Ant <Ant_member pathlink.com> writes:

In article <cnscro$1on8$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Ant wrote:

 thank you.
 
 any reports of DUI working on other platforms are welcome!

Since it currently has "Win32" and "linux" hardcoded,
it won't compile on platforms other than those two...

Neither dool nor DUI compiles.
(bug reports on SourceForge)

--anders

My fault! :(
what should I do? just use "else" instead of linux?

Ant

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ant wrote:

Since it currently has "Win32" and "linux" hardcoded,
it won't compile on platforms other than those two...

Neither dool nor DUI compiles.
(bug reports on SourceForge)

 
 My fault! :(
 what should I do? just use "else" instead of linux?

Yes, you could start by doing that and any real linux
dependencies could be found further down the road...

It was covered in another thread, but version(Unix) is broken
Aiming for the regular C library / POSIX stuff is usually good


SourceForge has Mac OS X in their compile farm, I think ?

--anders

Ant <Ant_member pathlink.com> writes:

In article <cnv7fn$ess$1 digitaldaemon.com>, 
SourceForge has Mac OS X in their compile farm, I think ?

I don't think I have the time or the will to learn how to use it.
Would you try it if I changed it? Well, I'll change it anyway.

Ant

Ant <Ant_member pathlink.com> writes:

Since it currently has "Win32" and "linux" hardcoded,
it won't compile on platforms other than those two...

Neither dool nor DUI compiles.
(bug reports on SourceForge)

thank you, I didn't notice that until now.
I'll try to change the version statments.
I'll let you know when (I believe) it's ready to try again.

Ant

h3r3tic <foo bar.baz> writes:

Ant wrote:
 PS sorry for sequestring the D group for DUI...

I don't think this is a problem to anyone. D needs a good GUI and DUI 
can provide it :)

Regan Heath <regan netwin.co.nz> writes:

On Mon, 22 Nov 2004 01:11:29 +0100, h3r3tic <foo bar.baz> wrote:
 Ant wrote:
 PS sorry for sequestring the D group for DUI...

 I don't think this is a problem to anyone. D needs a good GUI and DUI 
 can provide it :)

Not a problem, however it might be 'nicer' if you had your own group, like 
on dsource or wherever. I think 'announcements' and 'problems' should be 
posted here and possibly their resolutions (if applicable to other D 
projects)

The various posts discussing and solving the problem could be in their own 
group, but, then again if someone is not interested they can simply ignore 
the thread can't they.

Perhaps a digitalmars.D.gui NG is a good idea? We have one for the DTL, 
why not one for gui related discussions it occurs to me that is a large 
subject area which will only get more and more traffic as D evolves.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

John Reime <John_member pathlink.com> writes:

In article <opshubbtna5a2sq9 digitalmars.com>, Regan Heath says...
On Mon, 22 Nov 2004 01:11:29 +0100, h3r3tic <foo bar.baz> wrote:
 Ant wrote:
 PS sorry for sequestring the D group for DUI...

 I don't think this is a problem to anyone. D needs a good GUI and DUI 
 can provide it :)


<snip>

Perhaps a digitalmars.D.gui NG is a good idea? We have one for the DTL, 
why not one for gui related discussions it occurs to me that is a large 
subject area which will only get more and more traffic as D evolves.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


I like that idea... GUI programming discussions would likely be popular because
that's the next area D needs to advance.  I think the gui question is one of the
first queries made by many new people to this group.  D needs one badly.
Currently, it seems that DUI is the strongest project in this area.

Ant doesn't seem to like the dsource.org forum format, which is sad.  It would
be nice to see that project in subversion there. And I don't like the Yahoo
discussion groups one bit. :-(

It would be nice to work something out...

John

"Simon Buchan" <currently no.where> writes:

On Mon, 22 Nov 2004 13:22:31 +1300, Regan Heath <regan netwin.co.nz> wrote:

<snip>
 Perhaps a digitalmars.D.gui NG is a good idea? We have one for the DTL,  
 why not one for gui related discussions it occurs to me that is a large  
 subject area which will only get more and more traffic as D evolves.

 Regan

Well I dont know if a gui group would get enough traffic for a while (I  
only
know about DUI atm) but perhaps a more general .D.projects?

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Ant <duitoolkit yahoo.ca> writes:

ok, here is what I have:

on the libs opengl32 and glu32 found on windows\system32.

- if I use extern(C) on gl.d and glu.d (from gl.h and glu.h)
   programs crash with "Acess Violation" UNLESS the -g flag is used
- if I use extern(Windows)
   I get :
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glFlush 0
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glLightfv 12
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glLightModelfv 8
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glEnable 4
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glMaterialf 12
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glPopMatrix 0
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glClearColor 16
testGL\TestGL.obj(TestGL)
(more...)

So, seems I messed up somewhere else... where?

I created the import libs with implib:
\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\opengl32.lib
C:\WINNT\system32\opengl32.dll
\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\glu32.lib
C:\WINNT\system32\glu32.dll

Ant

John Reimer <John_member pathlink.com> writes:

In article <cnui5s$2c3i$1 digitaldaemon.com>, Ant says...
ok, here is what I have:

on the libs opengl32 and glu32 found on windows\system32.

- if I use extern(C) on gl.d and glu.d (from gl.h and glu.h)
   programs crash with "Acess Violation" UNLESS the -g flag is used
- if I use extern(Windows)
   I get :
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glFlush 0
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glLightfv 12
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glLightModelfv 8
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glEnable 4
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glMaterialf 12
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glPopMatrix 0
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glClearColor 16
testGL\TestGL.obj(TestGL)
(more...)

So, seems I messed up somewhere else... where?

I created the import libs with implib:
\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\opengl32.lib
C:\WINNT\system32\opengl32.dll
\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\glu32.lib
C:\WINNT\system32\glu32.dll

Ant


Ant, 

This is the an old problem with digitalmars' implib tool.  It is unable to make
usable import link libraries from the system dll's (specifically, it doesn't

total size in bytes of each functions parameter list).  This postfix is required
by digitalmars compilers to describe exported functions of the WINAPI type (thus
the need for extern(Windows) for opengl symbols).

What a few of us have finally found out is that you must make a "def" file to
get the symbols "mapped" appropriately.  There have been several discussions
about this over at dsource.org.  Because this problem with opengl32 libs was
cropping up so often amongst newcomers to D on windows, I finally commited some
*.def files to subversion within the win32 Bindings project.  I must say that
I've really come to appreciate how wonderfully simple Linux is in comparison to
windows (when it comes to linking libraries with your programs).

The opengl32.def and glu32.def files are used exactly the same as the
opengl32.lib and glu32.lib implibs;  that is, you link them with the d object
file as if they were a link library.  They allow your program to link properly
to the dll's (in fact you could make the actual implibs out of them if you want,
but it's not necessary).

Download them here:

http://svn.dsource.org/svn/projects/bindings/trunk/def/

Place them in one of your dm\lib or dmd\lib directories and link them in along
with the other libs used by your program.  All undefined symbols should be
eliminated.  Tell me how it works.

Later,

John

Ant <duitoolkit yahoo.ca> writes:

On Tue, 23 Nov 2004 09:28:19 +0000, John Reimer wrote:

 This is the an old problem with digitalmars' implib tool.  It is unable to make
 usable import link libraries from the system dll's

 
 http://svn.dsource.org/svn/projects/bindings/trunk/def/
 

thank you, I'll try that later tonight.

Ant

Ant <duitoolkit yahoo.ca> writes:

John Reimer wrote:

 This is the an old problem with digitalmars' implib tool.  It is unable to make
 usable import link libraries from the system dll's


 What a few of us have finally found out is that you must make a "def" file to
 get the symbols "mapped" appropriately.
 Download them here:
 
 http://svn.dsource.org/svn/projects/bindings/trunk/def/
 
 Place them in one of your dm\lib or dmd\lib directories and link them in along
 with the other libs used by your program.  All undefined symbols should be
 eliminated.  Tell me how it works.

seems that doesn't work with link.exe.
"
\dantfw\GTK\lib\opengl32.def
  Error 43: Not a Valid Library File
"
I always compile and link in to steps.
Is it possible to make work with link.exe ?

Ant

John Reimer <John_member pathlink.com> writes:

In article <co0o3v$2lt5$1 digitaldaemon.com>, Ant says...
John Reimer wrote:

 This is the an old problem with digitalmars' implib tool.  It is unable to make
 usable import link libraries from the system dll's


 What a few of us have finally found out is that you must make a "def" file to
 get the symbols "mapped" appropriately.
 Download them here:
 
 http://svn.dsource.org/svn/projects/bindings/trunk/def/
 
 Place them in one of your dm\lib or dmd\lib directories and link them in along
 with the other libs used by your program.  All undefined symbols should be
 eliminated.  Tell me how it works.

seems that doesn't work with link.exe.
"
\dantfw\GTK\lib\opengl32.def
  Error 43: Not a Valid Library File
"
I always compile and link in to steps.
Is it possible to make work with link.exe ?

Ant


Sorry, Ant,

I assumed the linker would accept it the same way, but I guess it works only
with the dm and dmd compiler command line.

To convert the "def" files to import libraries do:

implib glu32.lib glu32.def
implib opengl32.lib opengl32.def

where implib is the digitalmars one and the *.lib are the resulting import
libraries.

I hope that does it.  I think I'll upload the two libraries to the Bindings
project so that people won't have to convert it themselves in the future.

Later,

John

Ant <duitoolkit yahoo.ca> writes:

On Wed, 24 Nov 2004 06:20:13 +0000, John Reimer wrote:

 In article <co0o3v$2lt5$1 digitaldaemon.com>, Ant says...
 
 Sorry, Ant,

hey, thank you for your help, no need for appologises!

It's taken 1 year to get to this stage but I think we'll get it!

It compiled but my windows box froze when I pressed "run".

ok, login dialog is up... exe file was lost on crash,
recompiling... it works!

took 1 year to solve this problem.

Thanks, John!

Next version of DUI will have Support for OpenGL.

Ant

Ant <duitoolkit yahoo.ca> writes:

On Wed, 24 Nov 2004 01:30:23 -0500, Ant wrote:

 
 Next version of DUI will have Support for OpenGL

(I mean the windows version, the linux version has it since I can remember.)

fix for DUI windows 00.20_100:

I uploaded a zip with the 2 import libs opengl32.lib and glu32.lib
and the gl.d files
replace the ones distributed with duiInstaller_100.zip with these ones
the libs should be at
<your dantfw path>\Gtk\lib
the gl.d files should be at:
<your dantfw path>\duiD\src\gl

http://sourceforge.net/project/showfiles.php?group_id=97723&package_id=136197&release_id=284444

Ant

John Reimer <John_member pathlink.com> writes:

In article <pan.2004.11.24.06.30.22.253826 yahoo.ca>, Ant says...

<snip>

took 1 year to solve this problem.

Thanks, John!

Next version of DUI will have Support for OpenGL.

Ant


Your welcome!  Glad I could help! 

:-)

John Reimer <John_member pathlink.com> writes:

And just to clarify,  I have succeeded in getting DUI's opengl working with
windows (using XP).  All DUI Opengl test programs compile and run fine now.  :-)


In article <cnui5s$2c3i$1 digitaldaemon.com>, Ant says...
ok, here is what I have:

on the libs opengl32 and glu32 found on windows\system32.

- if I use extern(C) on gl.d and glu.d (from gl.h and glu.h)
   programs crash with "Acess Violation" UNLESS the -g flag is used
- if I use extern(Windows)
   I get :
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glFlush 0
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glLightfv 12
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glLightModelfv 8
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glEnable 4
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glMaterialf 12
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glPopMatrix 0
testGL\TestGL.obj(TestGL)
  Error 42: Symbol Undefined _glClearColor 16
testGL\TestGL.obj(TestGL)
(more...)

So, seems I messed up somewhere else... where?

I created the import libs with implib:
\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\opengl32.lib
C:\WINNT\system32\opengl32.dll
\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\glu32.lib
C:\WINNT\system32\glu32.dll

Ant

"Walter" <newshound digitalmars.com> writes:

"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.11.21.23.07.12.189217 yahoo.ca...
 John Reimer found that

 replacing extern(C) with extern(Windows) on the
 DUI OpenGL extension decalrations fixes all the problems
 with the OpenGL on DUI.

Hmm. This sounds like it could be the cause of the crashing problem you were
having when not using -g. Not using -g sets up a slightly different stack
frame with different cleanup algorithms.