Archived

This topic is now archived and is closed to further replies.

Kojak

To Dll or not ?!

Recommended Posts

Kojak    122
I''m working on a structure for a "ideal wonderful multi platform...el perfecta" game engine! I''m stuck... ;( Should I use dynamic dll or static dll ?! Or should I use nothing at all ?! Or something else ?! thanx KOjak

Share this post


Link to post
Share on other sites
griffenjam    193
Well, In my opinion, I would not use a dll unless you intent to allow the system to recieve new dlls that will enhance its use.
In other words, have a graphics dll that will handle all your graphics creation/drawing/destruction, use a generic interface. That way if you, after release, find a faster way of doing something you can just update the dll and send that out as a patch. Or if multiple programs all use the same interface.
Otherwise using a dll is a waste. It adds to disk space and memory useage.

BTW If you do have multiple programs calling the same interface, stope that interface in a common files directory somewhere, don''t put it in \Windows\system. I hate it when programs do that.

Jason Mickela
ICQ : 873518
E-Mail: jmickela@sbcglobal.net
-Making "alot" a real word one paragraph at a time.-


-Can''t sleep, clown''ll eat me, can''t sleep, clown''ll eat me.

Share this post


Link to post
Share on other sites
Promit    13246
Be aware that most people have the tools to take a look at the exported calls, and use them happily for themselves. if you dont want that, dont use DLLs.

Static DLLs are never really useful. Don''t bother.

The best interface for a graphics and/or game engine library is to use COM. This way, a lot of OOP is available. Of course, COM is a little hard to understand at first, but it pays off.

The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.

Share this post


Link to post
Share on other sites
Houdini    266
quote:
Original post by Promit
The best interface for a graphics and/or game engine library is to use COM. This way, a lot of OOP is available. Of course, COM is a little hard to understand at first, but it pays off.



Why is this exactly? COM forces you to return HRESULTS for every function, unlike DLLs (I''m sorry, but any external library that requires you to redesign your classes is a Bad Thing, imo). COM doesn''t allow easy porting to other operating systems, unlike DLLs (because of this redesign). COM is harder to use/understand than DLLs. COM forces registration before use, unlike DLLs.

BTW, Microsoft has pretty much done a 180 with external libraries in .NET, going back to DLLs instead of the messy COM approach.


- Houdini

Share this post


Link to post
Share on other sites
Houdini    266
quote:
"Multiplatform" "DLL" Find the error.


I don''t believe anybody said a DLL is multiplatform. However, it is a very trivial task to convert from, say, a normal .DLL (Windows) to a .SO (Linux). That''s not true with COM DLLs.


- Houdini

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by Promit
Be aware that most people have the tools to take a look at the exported calls, and use them happily for themselves. if you dont want that, dont use DLLs.

The same can be done with static libraries.

Static DLLs are never really useful. Don''t bother.

Bullnickie! Statically linking programs can reduce dependencies on DLLs, which is usually a pro if the DLL is application specific, and only one instance of the program will be running at once.

The best interface for a graphics and/or game engine library is to use COM. This way, a lot of OOP is available. Of course, COM is a little hard to understand at first, but it pays off.

Sorry, but that''s a whole load of pig poop. Stay away from COM. It will make you pragmatically impotent.

The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.

It seems that a lot of natural intelligence (ie. Promit) also lack intelligence.


Share this post


Link to post
Share on other sites