www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extern(C) / extern(Windows) - DUI OpenGL

reply 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.
Nov 21 2004
next sibling parent reply 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...
Nov 21 2004
next sibling parent reply =?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
Nov 21 2004
parent reply 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
Nov 21 2004
parent reply =?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
Nov 22 2004
next sibling parent reply 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
Nov 22 2004
parent reply =?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
Nov 23 2004
parent 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
Nov 23 2004
prev sibling parent 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
Nov 22 2004
prev sibling parent reply 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 :)
Nov 21 2004
parent reply 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/
Nov 21 2004
next sibling parent 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
Nov 21 2004
prev sibling parent "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/
Nov 22 2004
prev sibling next sibling parent reply 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
Nov 22 2004
next sibling parent reply 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
Nov 23 2004
next sibling parent 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
Nov 23 2004
prev sibling parent reply 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
Nov 23 2004
parent reply 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
Nov 23 2004
parent reply 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
Nov 23 2004
next sibling parent 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
Nov 23 2004
prev sibling parent 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! :-)
Nov 23 2004
prev sibling parent 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
Nov 23 2004
prev sibling parent "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.
Nov 23 2004