1. Euphoria and Xwindows
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Jul 21, 1999
-
Last edited Jul 22, 1999
Good news.
The wrapper for the GraphApp library is turning out to be much easier than I
expected. Already I have most controls wrapped, as well as graphics primitives
such as rectangles (filled and empty) arcs (ditto) ellipse ("}
rounded-rectangles (") polygons (") and text of all colors.
All of this stuff works very nicely, and in a euphorish manner.
Callbacks to Euphoria functions are next, and I may wait until tomorrow to do
those. Fonts and image routines look harder.
So far, it looks like this is going to be a good solution to using windows on
Linux (or on Windows, for that matter).
Regards,
Irv
2. Re: Euphoria and Xwindows
Irv Mullins wrote:
>So far, it looks like this [GraphApp] going to be a good
> solution to using windows on Linux (or on Windows, for
> that matter).
Neat.
GraphApp looked cool, but I couldn't figure out how to get it to compile on
my machine. The stupid Borland C++ compilers all demand that their own class
libraries be used. I guess I should have tried it under Linux first.
Since you can detect what platform you are on (and thus what files to link
to), I'm assuming that you only need to support one set of files for the
Win32 and Linux.
Now, if only Pete could get Peu to work on the Mac...
-- David Cuny
3. Euphoria and Xwindows
I have not completed the Euphoria wrapper for GraphApp, but there's enough
working for me to post a demo. The demo, wrapper, and a pre-compiled library
(which is quaranteed to work only on my personal pc running SuSE 6.1) and links
to the GraphApp site are now on my webpage: http://www.mindspring.com/~mountains
This is by far the easiest "windows" programming i have ever done; both the
souce code and the results look nice.
Thanks in advance for your feedback or contributions to completing the wrapper
(please coordinate via e-mail if you can help)
Regards,
Irv
4. Re: Euphoria and Xwindows
Irv:
Could you also get a Windows version of the DLL posted?
Thanks!
-- David Cuny
5. Re: Euphoria and Xwindows
Irv:
I took a look at your GRAPHAPP.E file, and noticed you are wrapping the
calls as:
global procedure fill_arc (sequence coords, integer start, integer fini)
atom fa
fa =
c_proc(fa, {coords[1], coords[2], coords[3], coords[4], start, fini})
end procedure --void fillarc(rect r, int start_angle, int end_angle);
You only need to declare the C proc once, like this:
constant fill_arc_ =
global procedure fill_arc (sequence coords, integer start, integer fini)
c_proc(fill_arc_, {coords[1], coords[2], coords[3], coords[4], start,
fini})
end procedure
That should speed up your calls a bit.
-- David Cuny
6. Re: Euphoria and Xwindows
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Jul 22, 1999
-
Last edited Jul 23, 1999
On Thu, 22 Jul 1999, you wrote:
> Could you also get a Windows version of the DLL posted?
>
> Thanks!
>
> -- David Cuny
Unfortunately, only the 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?
Irv
7. Re: Euphoria and Xwindows
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
8. 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
9. Re: Euphoria and Xwindows
Hi, Gary.
Thanks for the information. 
I'll pass it along to Pete and Robert - perhaps one of them can be convinced
to add GraphApp to Euphoria. That would take care of the problem. Peu is
possible.
-- David Cuny
10. Re: Euphoria and Xwindows
Ooops...
Gotta pay attention to *where* my e-mail is coming from.
-- David Cuny
11. Re: Euphoria and Xwindows
As Gary wrote (more or less)
> ... GraphApp doesn't play well as a Win32 DLL...
So Robert, is there any possibility of getting a version of GraphApp
embedded into Euphoria, or is there a problem with licensing/you'd prefer
not to tie Euphoria to another product/some other compelling reason?
Just wondering.
-- David Cuny
12. Re: Euphoria and Xwindows
On Mon, 26 Jul 1999, you wrote:
> As Gary wrote (more or less)
>
> > ... GraphApp doesn't play well as a Win32 DLL...
>
> So Robert, is there any possibility of getting a version of GraphApp
> embedded into Euphoria, or is there a problem with licensing/you'd prefer
> not to tie Euphoria to another product/some other compelling reason?
>
> Just wondering.
>
> -- David Cuny
I wouldn't be too anxious to adopt GraphApp (or any other) windowing package as
a permanent part of Euphoria. I personally don't like the look and feel of some
of the controls - sle and mle to be specific. These are things Iwould feel
compelled
to fix if I were developing software for pay.
Nevertheless, it does seem to be the easiest to use of the packages I've looked
at so far.
Irv
13. Re: Euphoria and Xwindows
On Mon, 26 Jul 1999 10:13:52 -0700, Cuny, David <David.Cuny at DSS.CA.GOV>
wrote:
>As Gary wrote (more or less)
>
>> ... GraphApp doesn't play well as a Win32 DLL...
>
>So Robert, is there any possibility of getting a version of GraphApp
>embedded into Euphoria, or is there a problem with licensing/you'd prefer
>not to tie Euphoria to another product/some other compelling reason?
>
>Just wondering.
>
>-- David Cuny
David
Can't someone just write an interface that translates the calls to GraphApp
to win32lib GDI calls? The translator could be put in a DLL.
PS did you come up way to extend create function in win32lib.
Have you used drawBitmap, does have any bugs in it ?
Bernie
14. Re: Euphoria and Xwindows
Bernie wondered:
> Can't someone just write an interface that
> translates the calls to GraphApp to win32lib
> GDI calls?
That would mean basically re-writing the Win32 portion of the GraphApp
library.
> Did you come up way to extend create function in win32lib.
No, you are right - there is no trivial way to pass the parameter. What
*specifically* are you trying to create? Perhaps that might help a bit.
> Have you used drawBitmap, does have any bugs in it ?
As far as I know, the bitmap code in Win32Lib works. The confusion was that
createDIB expected zero-based indexes, not 1 based indexes. I had changed
this to match the Euphoria bitmap code. This is another place I was suprised
to find the Euphoria used zero-based indexes.
-- David Cuny
15. Re: Euphoria and Xwindows
Thanks David
Bernie
16. Re: Euphoria and Xwindows
David Cuny writes:
> So Robert, is there any possibility of getting a
> version of GraphApp embedded into Euphoria,
> or is there a problem with licensing/you'd prefer
> not to tie Euphoria to another product/some other
> compelling reason?
I tried out Irv's example programs and GraphApp wrapper,
and I was impressed with how much he's been able to do
in a short time, and with the simplicity of his example code.
I used Red Hat 5.2.
I don't plan to "embed" GraphApp into Euphoria.
Irv seems to be doing fine without my doing that.
My basic philosophy is to only put stuff into exu (ex.exe, exw.exe)
that really *has* to be there. I'm always happier to implement
a library routine in Euphoria than in C. For example,
sort(), display_image(), read_bitmap() etc. could have
been done in C inside the interpreter to gain a bit of
performance, but I'd rather have library source code
that is open, and easily modified by users or myself.
It also saves memory for programs that don't need the
library routine.
GraphApp is covered by the GNU library licence, so as a
static library it has "strings" attached to it that I would
like to avoid. Even as a dynamic library I don't think I want
to fill up exu with calls to it. Euphoria users are completely
free to dynamically link with it and use it.
I wouldn't rule out the possibility of *ever* statically
linking with a GNU library, but for the time being I
don't want to cross that line.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
17. Re: Euphoria and Xwindows
Robert Craig wrote:
> I wouldn't rule out the possibility of *ever*
> statically linking with a GNU library, but for
> the time being I don't want to cross that line.
Oh, well. Now all I need to do is find a great free C-based cross-platfrom
library that's not GNU...
-- David Cuny
18. Re: Euphoria and Xwindows
It was a dark and stormy night when Robert Craig wrote:
> David Cuny writes:
> > So Robert, is there any possibility of getting a
> > version of GraphApp embedded into Euphoria,
> > or is there a problem with licensing/you'd prefer
> > not to tie Euphoria to another product/some other
> > compelling reason?
>
> I tried out Irv's example programs and GraphApp wrapper,
> and I was impressed with how much he's been able to do
> in a short time, and with the simplicity of his example code.
> I used Red Hat 5.2.
>
> I don't plan to "embed" GraphApp into Euphoria.
> Irv seems to be doing fine without my doing that.
>
> My basic philosophy is to only put stuff into exu (ex.exe, exw.exe)
> that really *has* to be there. I'm always happier to implement
> a library routine in Euphoria than in C. For example,
> sort(), display_image(), read_bitmap() etc. could have
> been done in C inside the interpreter to gain a bit of
> performance, but I'd rather have library source code
> that is open, and easily modified by users or myself.
> It also saves memory for programs that don't need the
> library routine.
I tend to agree. Sooner or later, someone will implement SVGALIB
calls in order to do high speed graphics. And, with all the different Xwindows
libraries, someone will find a better one than GraphApp.. In either case, it
wouldn't help them if Euphoria came bundled with a lot of (what would be to
them) useless functions.
Rob: It sure would help if there were a debugging version of Eu for Linux
(Hint, hint)
I am getting a lot of 300 line errors, since the GraphApp file is around 1300
lines. Most of the problems can be traced out, but there are some that result
in a "seqmentation fault" and I have no idea what that even means, much less
how to fix it.
Regards,
Irv
19. Re: Euphoria and Xwindows
Irv wrote:
> Most of the problems can be traced out, but there are
> some that result in a "seqmentation fault" and I have
> no idea what that even means, much less how to fix it.
A "segmentation fault" happens when a program writes to a memory area
(segment) not allocated to it.
-- David Cuny
20. Re: Euphoria and Xwindows
David,
I'm sure you've heard of wxWindows at:
You may also want to look at VWCL at:
http://www.vwcl.org/
Gary.
On Mon, 26 Jul 1999 15:10:41 -0700, Cuny, David <David.Cuny at DSS.CA.GOV>
wrote:
>Robert Craig wrote:
>
>> I wouldn't rule out the possibility of *ever*
>> statically linking with a GNU library, but for
>> the time being I don't want to cross that line.
>
>Oh, well. Now all I need to do is find a great free C-based cross-platfrom
>library that's not GNU...
>
>-- David Cuny
21. Re: Euphoria and Xwindows
Gary Dumer wrote:
> I'm sure you've heard of wxWindows at ...
By all accounts, an excellent C++ library, especially with version 2.0. For
a while, I considered wrapping the stuff in a DLL, but there's just too much
there!
> You may also want to look at VWCL at ...
A C++ class library - not portable to Euphoria in a trivial sort of way.
By way of contrast, take a look at GTK+, at:
www.gtk.org
Thanks for the input!
-- David Cuny
22. Re: Euphoria and Xwindows
Irv Mullins writes:
> Rob: It sure would help if there were a debugging
> version of Eu for Linux (Hint, hint)
> I am getting a lot of 300 line errors,
There isn't much more to do before I start calling
them "alpha" rather than "pre-alpha" releases, and
I have a Complete Edition available for Linux.
binding and shrouding are now working on Linux.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
23. Re: Euphoria and Xwindows
>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.
>
>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.
>
>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.
While this is definitely the case with 16-bit Windows (Windows 3.x), 32-bit
Windows (95/98/NT/2000) does not have this problem.
Quoting from "Advanced Windows" by Jeffrey Richter:
"DLLs in Win32 don't receive their own local heaps. Second, a Win32 DLL's
global and static variables are not shared among multiple mappings of the
DLL - the system creates an instance of the global data for each process,
and each instance will not have the same value when the DLL is mapped into
multiple processes' address spaces."
It turns out, that this (that DLL's no longer share global data) is one of
the problems in porting from 16-bit to 32-bit windows. Sharing data among
multiple processes is much harder in 32-bit windows than 16-bit Windows. 32-
bit Windows tries very hard to keep you from messing with other peoples
data. There is a way to share data among DLL's in 32-bit Windows, but it
won't just happen without additional work on the part of the programmer.
Unless GraphApp is doing something really strange (and from first glance,
it appears to be very tame), it should be possible to compile it as a Win32
DLL, without any "shared memory" problems. Of course someone has to make
all the necessary functions and data exportable, which is compiler
dependant, but once that is done, it should (theoretically) be easy. <grin>
(it always seems easy, if you're not the one who is actually doing it!)
So don't give up quite yet!
--
Sammy Mitchell
24. Re: Euphoria and Xwindows
Sammy Mitchell wrote:
> DLLs in Win32 don't receive their own local heaps.
All right!
-- David Cuny
