what's the difference derelict and a header converted to D ?

clayasaurus · Joined: 21 May 2004 Posts: 857

hello, derelict sounds like a cool idea and all, but i have to ask 1 question.

for my own project, i've converetd a bunch of .h files to .d and got programs to work with them.

so, what's the difference between Derelict and my .d headers

http://svn.dsource.org/svn/projects/claytek/trunk/claytek/c/

i think i might know one difference ,that i've only tested mine on linux.

what else? thx.

aldacron · Posted: Tue Jun 15, 2004 3:16 pm Post subject:

Look at that. I went and added SDL and GLU to Derelict because you requested them, and now you aren't even using them! Wink

The only difference is in how the shared libraries are loaded. Your bindings require the app to be linked to an import library, causing the shared library to be loaded automatically by the OS at app startup. Derelict is set up to load the shared libraries manually.

The reason is primarily to avoid the case where the shared library is missing or corrupt on the user's system. I don't know what happens on Linux in that case, but on Windows the user gets a very unfriendly message box stating that a required DLL is missing, and the app never starts. It looks very unprofessional and makes a very angry user. Even if you distribute the DLL with your app, who knows what the user will do with it?

So this approach bypasses that ugly message box. If a DLL fails to load for whatever reason, Derelict will throw an exception, the app can catch it and respond appropriately. The response might be to put up an app-specific message box with info on how to contact support, or it might be to load an alternative behind the scenes (like using a D3D renderer if OpenGL fails to load).

So that's the difference. I've used this approach in C for a long time, and was a little put off by the existing D bindings in that they all require you to link to an import lib. With something like opengl, it's not really a big deal. In C, I usually put my renderer implementations in their own DLLs linked to the import lib, and just load those manaually. If Opengl is not present, then the ogl renderer DLL will fail to load.

Anyway, it's just an additional option to what's already out there.

JJR · Joined: 22 Feb 2004 Posts: 1104

And don't forget to mention that it also brings several of the most important graphics libs together into a nicely organized package. No more hunting all over d-dom to find the variations of SDL, OpenGL, and Glee stuff... That in itself makes it desirable...

clayasaurus · Joined: 21 May 2004 Posts: 857

aldacron · Posted: Wed Jun 16, 2004 4:05 am Post subject:

Heh, actually I'm really glad you convinced me to put SDL and glu in so soon. No one likes using raw system calls to setup opengl, so SDL makes the project more friendly from the start. I still need to get it ported to Linux. I'm not too keen on reviving my Linux partition right now.

I had a custom built distro which started with Linux From Scratch as a base. I was so proud of myself when I first booted it after three days of compiling and installing the bare system (I'm still a Linux-noob, even after five years of toying off and on). Somewhere along the line I got in over my head and and it's rather useless at the moment. The idea of installing from one of the RH/Mandrake/Suse CDs I have lying around, updating XFree86 , the Nvidia drivers, the dev toolchain and whatever else, is less than appealing.

But if noone takes on the Linux version of Derelict in the next few weeks, I'll roll up my sleeves and get it done.