| View previous topic :: View next topic |
| Author |
Message |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
 Posted: Fri Feb 11, 2005 11:20 pm Post subject: |
 |
|
| You're right. Glx is a big port. It would make a derelict sub-project of it's own, and a big one at that. I'll see what I can do with it. Maybe if a I plug away, something will eventually be produced. It would be even better if I could automate the process. |
|
| Back to top |
|
 |
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Feb 12, 2005 4:47 am Post subject: |
|
|
| I tweaked glfw.d a bit. The first thing is that I put it in a glfw subdirectory to match the other Derelict packages, so it is now derelict.glfw.glfw. I also ripped the DLL loading code out of the versioned DerelictGLFW_Load functions, renamed the functions to a 'private void load', and created a new DerelictGLFW_Load outside of the version statements. Finally, I added code to intialize std.loader (which isn't strictly necessary since ExeModule_Init doesn't really do anything, but in case it one day does) and a module destructor to unload the dll. I also created the Windows Makefile, and will get around the README and Makefile.linux soon. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 12, 2005 5:35 am Post subject: |
|
|
| aldacron wrote: | | I tweaked glfw.d a bit. The first thing is that I put it in a glfw subdirectory to match the other Derelict packages, so it is now derelict.glfw.glfw. I also ripped the DLL loading code out of the versioned DerelictGLFW_Load functions, renamed the functions to a 'private void load', and created a new DerelictGLFW_Load outside of the version statements. Finally, I added code to intialize std.loader (which isn't strictly necessary since ExeModule_Init doesn't really do anything, but in case it one day does) and a module destructor to unload the dll. I also created the Windows Makefile, and will get around the README and Makefile.linux soon. |
Hello Mike,
I like your changes. I'm glad you cleaned it up a little. I resorted to derelict.glfw instead of derelict.glfw.glfw because I dislike the redundancy in the name (and there's only a sngle file in the glfw directory in this case). I know phobos does it that way, but I think it looks strange. But better to be consistant with derelict and the rest of the d world, so no problemo. 
It also looks like you added the appropriate Linux version statements too. I'll have to test it out on Linux to see if it works.
I also just thought of possible problem with the windows version of these dll loaders. There still might be a danger on windows loading a genericly named dll like glfw.dll. That seems unsafe, but I guess that's the way Windows has always worked. An updated incompatible dll could replace it and cause problems with the programs that link to it. I guess not much we can do on our part. Linux is much more reliable in this regard.
Concerning GLX:
I've basically completed a glx.d loader for Linux. It's contains the basic glx functions (quite a few!). I excluded the glxext functions because there's a whole bunch of them and I don't know which are available and which are not (lots of #ifdef in the C headers). The glext functions can be added later on a "as-needed" basis. I have yet to test the loader out to see how it works. I'll need to find a sample program to convert that uses the glx functions since I don't know how to use glx myself. You were right, though. It took a few hours of hunting down structures hiding in the deep recesses of the X11 header tree to get everything together... pheww... I'm tired!
Later,
John Reimer |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Feb 12, 2005 6:13 am Post subject: |
|
|
| JJR wrote: |
It also looks like you added the appropriate Linux version statements too. I'll have to test it out on Linux to see if it works.
|
Actually, the Linux stuff is yours
| Quote: |
I also just thought of possible problem with the windows version of these dll loaders. There still might be a danger on windows loading a genericly named dll like glfw.dll. That seems unsafe, but I guess that's the way Windows has always worked. An updated incompatible dll could replace it and cause problems with the programs that link to it. I guess not much we can do on our part. Linux is much more reliable in this regard.
|
You and I think differently on this  In the Windows world, it is no longer considered good practice for an application to dump DLLs in the System or System32 directories. Some still do, but the large majority of apps these days keep DLLs in its own directory tree. The ./ directory is the first place searched when DLLs are loaded, so there is usually no danger of conflicts. On the other hand, I find the Linux way to be quite confusing and obtuse. It would be so much simpler if I could ask for 'glfw.so' and not worry about version suffixes.
This reminds me of something I had thought of earlier. I want to go through each package and add an alternative load function that accepts a string as a parameter, so that an application can override the default library names that Derelict looks for. On Windows, for example, a dll might be in a subdirectory, or someone might want to use the SGI Opengl DLL rather than the Win32 API version. It also allows some flexibility when running apps on Linux.
| Quote: |
I've basically completed a glx.d loader for Linux. It's contains the basic glx functions (quite a few!). I excluded the glxext functions because there's a whole bunch of them and I don't know which are available and which are not (lots of #ifdef in the C headers). The glext functions can be added later on a "as-needed" basis. I have yet to test the loader out to see how it works. I'll need to find a sample program to convert that uses the glx functions since I don't know how to use glx myself. You were right, though. It took a few hours of hunting down structures hiding in the deep recesses of the X11 header tree to get everything together... pheww... I'm tired!
|
You're a braver man than I |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Sat Feb 12, 2005 6:25 am Post subject: |
|
|
I should really be sleeping right now! 
| aldacron wrote: | | JJR wrote: |
It also looks like you added the appropriate Linux version statements too. I'll have to test it out on Linux to see if it works.
|
Actually, the Linux stuff is yours
|
HA! I really, really should be sleeping right now! I forgot that I added it.
| aldacron wrote: | You and I think differently on this In the Windows world, it is no longer considered good practice for an application to dump DLLs in the System or System32 directories. Some still do, but the large majority of apps these days keep DLLs in its own directory tree. The ./ directory is the first place searched when DLLs are loaded, so there is usually no danger of conflicts. On the other hand, I find the Linux way to be quite confusing and obtuse. It would be so much simpler if I could ask for 'glfw.so' and not worry about version suffixes.
|
Good points. I guess it comes down to what we've accustomized ourselves to. I've used Windows for a long time, but the Linux way just seems safer and smarter to me (especially the ease of linking period: no implibs like windows). I agree that it may not be easy to understand the linux way. It took me quite awhile to know what I do now. As for just doing a glfw.so, you can for most systems that are smart enough to set up the symbolic links. But it appears you can't do that on some (like yours?) because those links aren't set up automatically. Mine were, so it wasn't a big deal. Strange... and confusing, yes.
| aldacron wrote: | | This reminds me of something I had thought of earlier. I want to go through each package and add an alternative load function that accepts a string as a parameter, so that an application can override the default library names that Derelict looks for. On Windows, for example, a dll might be in a subdirectory, or someone might want to use the SGI Opengl DLL rather than the Win32 API version. It also allows some flexibility when running apps on Linux. |
Sounds like a very good idea!
| aldacron wrote: | | Quote: |
I've basically completed a glx.d loader for Linux. It's contains the basic glx functions (quite a few!). I excluded the glxext functions because there's a whole bunch of them and I don't know which are available and which are not (lots of #ifdef in the C headers). The glext functions can be added later on a "as-needed" basis. I have yet to test the loader out to see how it works. I'll need to find a sample program to convert that uses the glx functions since I don't know how to use glx myself. You were right, though. It took a few hours of hunting down structures hiding in the deep recesses of the X11 header tree to get everything together... pheww... I'm tired!
|
You're a braver man than I |
Well either that or I'm just plain stupid! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
