Re: Euphoria and Xwindows
David... I have the correct compiler to create a DLL for Windows, but...
I had all kinds of problems with the Make so I wrote to Loki and got the
following reply. It doesn't look good for Windows.
Gary.
-------------------------
L. Patrick wrote:
GraphApp isn't really set up for compiling as a DLL for a few reasons.
Firstly, DLLs are loaded once, and then any memory used by that DLL
is shared by all the programs using the DLL. So, if one program
starts using a GraphApp DLL, all other GraphApp programs will be using
the same library memory space.
This wouldn't be a problem, except GraphApp makes extensive use of
global variables to make the interface to the library simple. In the
case of DLLs however, this means there can be only one program using
the DLL at one time, otherwise the globals would be screwed up by
having two programs use them simultaneously. (Actually, the first
program to use the DLL would work fine, but subsequent programs would
inherit the same data structures as the first program, so any new
windows created would be shared by all programs - it would be
unpredictable how the programs would interfere with each other).
Since only one program could use the DLL at one time, there is no
point in making it a DLL. A DLL is, by definition, meant to be
shared amongst many applications, but you cannot do that if you are
using global variables in the library, as GraphApp does.
The reason why you cannot remove the globals from GraphApp is due
to the fact GraphApp functions take so few parameters. Consider
the newwindow function which creates a new window data structure:
window newwindow(char *name, rect r, long flags);
To work with a DLL, it would be necessary to tell this function
from which application we wish to create the window, so that the
window is assigned into the appropriate data structure inside the
DLL's memory space (so that applications do not interfere with each
other). But how do you do that? You would have to use the Windows
"instance handle" parameter, which breaks the portability of the
library. Or, consider the drawing functions:
void drawline(point p, point p2);
This function is so simple because there is an implicit drawing
context (which is global) so the function doesn't need to be told
which window to draw to, it already knows. That's the power of
global variables; that's also the disadvantage of them. We'd have
to add the window as the first parameter to the function so the
DLL would know which window to draw to.
Another problem is that DLL's have an entry point which is a
function known as LibMain, while standard Windows applications
use an entry point called WinMain. GraphApp is set up to have a
WinMain, but I've never bothered to create a LibMain because I
was aware of the limitations of Windows DLLs.
The bottom line is GraphApp isn't designed to work as a DLL.
Interestingly, it effectively *does* work as a shared library on
X-Windows (Unix/Linux) platforms, because those operating systems
are superior to Windows' memory management. The problem is not
really to do with GraphApp, it's really a memory management issue
with the way Windows implements shared libraries. If you could tell
a DLL to be a shared code library, but to *not* use shared memory,
then everything would work fine.
Loki
>Irv Mullins wrote:
>
>> Unfortunately, only the [GraphApp] source is available,
>> and the website states that Turbo C and GCC "probably
>> will not work". It requires a "Windows compiler", which
>> I don't have. Maybe someone has MS C?
>
>The LCC compiler should work, but I can't figure out create a build file
>correctly. Maybe I should try reading the manual some time. 
>
>I took a look at the demo under Linux. Spiff!
>
>-- David Cuny
|
Not Categorized, Please Help
|
|
