1. Multi-Platform Support
This is (yet another) plug to Robert for cross-platform support built into
Euphoria.
The top two contenders on my wishlist have been Zinc (commercial) and
wxWindows (free). I slightly favored Zinc over wxWindows, because it had a
great DOS GUI. The down side was that it costs Big Money. wxWindows, on the
other hand, is an entirely *free* library. You can check it out at:
http://web.ukonline.co.uk/julian.smart/wxwin/
The 2.0 rewrite of wxWindows was recently released, and runs on the
following platforms:
Windows
GTK/Linux
Motif/Linux
a 2.x Mac port is currently in process, and is said to be progressing well.
The following ports are planned for then near future:
Qt/Linux
BeOS
WindowsCE
MGL/Windows, DOS, Linux, QNX, OS/2
Note that MGL (Scitech's MetaGraphics Library) runs on quite a few
platforms, including DOS. This pretty much would eliminate Zinc's advantage
of wxWindows.
Unlike some other "free" software, there is no irritating LGP licences to
worry about, so Robert can use it without having to compromise his source
code.
There is no question as to whether the library can be used for interpreted
languages - version 1.x was used as the front end for CLIPS, Python, Scheme,
XLisp and Perl. Python is currently running under 2.x. In fact, since the
Python source is open, it might even be possible to grab much of the API
bindings out of Python!
Finally, Ralf will happy to that wxWindows is implementing docking - and it
looks pretty cool.
So how about it, Robert? I'll be more than happy to port Win32Lib over to
wxWindows. 
-- David Cuny
2. Re: Multi-Platform Support
- Posted by Bernie Ryan <bwryan at PCOM.NET>
Mar 12, 1999
-
Last edited Mar 13, 1999
Please explain to me how a windows type framework for
C++ fits into using Euphoria.
3. Re: Multi-Platform Support
- Posted by Daniel Berstein <daber at PAIR.COM>
Mar 12, 1999
-
Last edited Mar 13, 1999
At 09:23 PM 12-03-1999 , you wrote:
>Please explain to me how a windows type framework for
>
>C++ fits into using Euphoria.
Euphoria ain't built in Euphoria. To my knowledge it's currently developed
by RDS using Watcom C++ v.11.
Regards,
Daniel Berstein
[daber at pair.com]
4. Re: Multi-Platform Support
Bernie Ryan wrote:
> Please explain to me how a windows type framework for
> C++ fits into using Euphoria.
I'm not sure I understand the question. Do you mean:
[How do you convert a C++ framework to Euphoria?]
This is done by creating a wrapper function that serves as an interface
between Euphoria and wxWindows. So your Euphoria code gets converted
internally into a call to wxWindows code.
As I mentioned earlier, there are a number of languages (CLIPS, Python,
Scheme, XLisp and Perl) - none of which are C++ - that allow the wxWindows
function to be called from within the language. Since most of these
applications are 'open source', it might even be possible to borrow large
chunks of pre-existing wrapper code.
[Why Not Write It In Native Euphoria?]
Because it's a never-ending process, and a lot of work to boot. Why
re-invent the wheel?
[C++ Is Impure]
[I Hate Anything To Do With C/C++]
[Linking Euphoria A C++ Framework Will Turn Euphoria into C++]
I think these arguments can be dismissed out of hand. Using wxWindows as the
GUI didn't fundamentally change the nature of any of the other programming
languages, and it won't change Euphoria, either.
[It'll Bloat Euphoria]
Possibly. But from the demos I've looked at, it shouldn't. And it doesn't
have seem to have a lot of hidden costs (VBRUN, DLLs, etc.) that are
associated with some languages.
Besides, I'm sure that if Robert adopted wxWindows, there would still be a
window-free version for people.
[Why Do I Want To Add Windows To Euphoria?]
Perhaps you don't. But adding windows support would certainly help with the
applications I'd like to write. And it would certainly help Euphoria gain
wider acceptance, and prevent it from dying an early death as the last of
the Great DOS Programming Languages.
Did that answer your question(s)?
-- David Cuny
5. Re: Multi-Platform Support
- Posted by Robert Craig <rds at ATTCANADA.NET>
Mar 13, 1999
-
Last edited Mar 14, 1999
David Cuny writes:
> So how about it, Robert? I'll be more than happy to
> port Win32Lib over to wxWindows.
Thanks for the link to wxWindows.
I surfed over and looked around, and I'm downloading
wxPython at this moment.
I'm not sure how much support you would need from the
Euphoria interpreter in order to port Win32Lib to sxWindows.
It seems to me that you could develop an interface DLL
(or UNIX shared library). Win32Lib.ew could call C routines in
that DLL just like you do now. The DLL would then call
wxWindows C++ routines, and manipulate C++ objects.
wxWindows would then call the WIN32 API or the API of
some other platform in order to do its thing.
Once the 2.1 official release is out, and I've distributed it
to all the big places around the Net, I will start porting
Euphoria to Linux. When the core port is complete I'll have
a much better grasp of cross-platform issues.
Thanks again for all the great work you've done on Win32Lib.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
6. Re: Multi-Platform Support
Robert
I think that the users should develop their own DLL's if they want to
interface to wxWindows. I think you should spend more time developing
new low level functions like get segemnt of a allocted memory block,
(match binary) binary search of a memory block, etc. In other words
give the user more and easier to use tools so the user can extend the
language. This is something that the user can't do because he does not
have access to the source code. Why spend your valuable time on a
a interface that all users may not use or need. Just give us more tools
and capabilty at a lower level. That is something everyone can use.
Thanks Bernie
7. Re: Multi-Platform Support
Robert replied to my wishlist about wxWindows:
>I'm not sure how much support you would need from the
>Euphoria interpreter in order to port Win32Lib to wxWindows.
Since the DLL approach means *you* wouldn't have to make any changes to
Euphoria, that probably lets you off the hook. I know that wxWindows has
it's own internal string class, but in theory string conversion would be
handled by the DLL.
Problematically, I have neither a Win32 C++ compiler, working knowledge of
C++, or a clue how to write a DLL. Anyone want to volunteer putting the DLL
together? Pete? I'm sure I can figure it out eventually.
If I'm really lucky, I can just use the DLL that comes with wxPython - at
least as a 'proof of concept' to get something going. But first I need to
wade through the wxWindows documentation. I highly recommend it for anyone
that's got insomnia.
If wxWindows does prove feasible, it would be nice if the support were built
directly into Euphoria. I guess I take a monolithic approach to software.
But one thing at a time.
>Thanks again for all the great work you've done on Win32Lib.
You're welcome. I should confess that I'll probably not be able to do much
actual coding in the next two months, things continuing to be what they are.
I'll do my best to get bugfixes into code, but new work on Win32Lib will
probably grind to a halt for a while.
Anyhoo, anything more at this point is just idle speculation, so back to the
documentation...
-- David Cuny
8. Re: Multi-Platform Support
Bernie Ryan wrote:
> I think that the users should develop their own DLL's if they want to
> interface to wxWindows.
While DLLs would be useful for interfacing to Win32 (and perhaps
Linux/FreeBSD), this appoach would not work for other platforms, such as
Dos32 and Macintosh.
-- David Cuny
9. Re: Multi-Platform Support
At 11:15 AM 14-03-1999 , you wrote:
>Robert
>
> I think that the users should develop their own DLL's if they want to
> interface to wxWindows. I think you should spend more time developing
> new low level functions like get segemnt of a allocted memory block,
Segments in Euphoria? Well on Win32 that makes no sense... on Dos32
neither! Euphoria (for DOS32) runs over the Causeway DOS extender, giving a
flat address space to the interpreter. Any alloted memory is (I belive)
handled by Causeway, so at it's best Euphoria might "publish" some
Causeway's memory managment routines. Something that I'm not sure anyone
could properly use without Causeway documentation (it's a commencial
product, http://www.devoresoftware.com/cwwmain.htm).
> (match binary) binary search of a memory block, etc. In other words
> give the user more and easier to use tools so the user can extend the
> language. This is something that the user can't do because he does not
> have access to the source code. Why spend your valuable time on a
> a interface that all users may not use or need. Just give us more tools
> and capabilty at a lower level. That is something everyone can use.
What would be great is see an Euphoria compiler. I've said on the past that
an Euphoria compiler wouldn't speedup THAT much code execution, but it do
have many benefits. An .obj output would do the job. I don't expect a small
company like RDS develop their own linker, librarian, resource compiler,
etc. The Lcc32 free compiler comes with those tools already. I can imagine
building Euphoria coded DLLs, mixing Eu code with C/Pascal/Asm, etc.
BTW Rob:
I was playing with EXE packers (my best choice is ASPack,
http://www.entechtaiwan.com/aspack.htm) and was unable to compress bounded
Euphoria programs (thinking about the Eu installer). The appended source is
trimmed out and the exe ask for the file to run. Then I tried compressing
pdexw.exe, so the bounded program use the already shrinked interpreter.
Same result. Have you any idea of how to make it work. The later method
should have worked... why it doesn't?
Regards,
Daniel Berstein
[ daber at pair.com ]
10. Re: Multi-Platform Support
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Mar 14, 1999
-
Last edited Mar 15, 1999
> What would be great is see an Euphoria compiler. I've said on the past that
> an Euphoria compiler wouldn't speedup THAT much code execution, but it do
> have many benefits. An .obj output would do the job. I don't expect a small
> company like RDS develop their own linker, librarian, resource compiler,
> etc. The Lcc32 free compiler comes with those tools already. I can imagine
> building Euphoria coded DLLs, mixing Eu code with C/Pascal/Asm, etc.
You cant compile a language meant to be interpreted.
All 'compiling' really is, is do some/a lot/huge amount of optimization at the
cost of 'compile-time'.
Take the JIT-technology for Java, is it interpreted or compiled ? Hard to tell.
What you want is a way to effectively communicate in *any* or (preferably) *all*
ways.
I am in favor of being able to bind to a DLL. Off course we would need a new
procedure which we use to define the exact
arguments and pointers/value issues. (if structures and arrays were available
btw, the pointer/value issue would be even less of
a problem)
I'm under the impression though, that object and library files are compiler
dependant and exist in many flavors, but I might be
wrong. (let's hope so)
Ralf
11. Re: Multi-Platform Support
Dan
To my knowledge no packer ( exe compresser ) will work on a EXE that
contains overlays.
If Euphoria uses the flat address model then can you tell me what
segment address it uses ? Also if I allocate_low some bytes what
segment address this uses. If these are always the same then
why isn't there a CONSTANT for these magic numbers in Euphoria.
All I want is:
An allocate_low function to return a sequence with { segment, offset }
A match function that searchs for a BINARY sequence in a memory block
Etc.
Bernie
12. Re: Multi-Platform Support
At 02:59 PM 14-03-1999 , you wrote:
>Dan
>
> To my knowledge no packer ( exe compresser ) will work on a EXE that
> contains overlays.
Oh no, it does work. You can pack exw.exe (I tried PE packers) and it will
gracefully execute your Euphoria program (exw myapp.exw). The problem is in
the way BIND.EXW appends data to the file and how exw.exe knows it has
appended code. Basically bind does a copy /b ex?.exe + myapp.ex?. I'm
asking Rob if he can make the appropiate changes so that if you pack
ex?.exe BEFORE binding, it still recognize there is appended data at the
end of the file.
I assume the file size of the interpreter is hardcoded onto the exe, and
that screw things when you pack it. If that is the case the binder (or
bounder?) might instead store at the end of the "compiled" program the
length of the appended data... a simple substraction will show the correct
offset.
But there will be another problem then, utilities like David's resource
builder won't work, in fact any program that appends data at the end of the
EXE will crash program execution. So the REAL solution would be that RDS
provide a new tool (resource.ex?) that allows the developer to append
arbitrary data to a bounded program. A simple LoadAppendedData() function
added to the language will let you access the data at runtime. These
changes/improvements should be easy to implement and would provide greater
flexibility to the developer.
> If Euphoria uses the flat address model then can you tell me what
> segment address it uses ? Also if I allocate_low some bytes what
> segment address this uses. If these are always the same then
> why isn't there a CONSTANT for these magic numbers in Euphoria.
> All I want is:
> An allocate_low function to return a sequence with { segment, offset }
I'm no asm guru, so I don't understand the "usefulness" of this information.
> A match function that searchs for a BINARY sequence in a memory block
That sounds more useful, specially for those gfx freaks out there ;)
Perhaps such a routine is already done by some Asm2Eu guru (Pete?, Lucius?)
for their graphic libraries.
Regards,
Daniel Berstein
[ daber at pair.com ]
13. Re: Multi-Platform Support
At 02:38 PM 14-03-1999 , you wrote:
>> What would be great is see an Euphoria compiler. I've said on the past that
>> an Euphoria compiler wouldn't speedup THAT much code execution, but it do
>> have many benefits. An .obj output would do the job. I don't expect a small
>> company like RDS develop their own linker, librarian, resource compiler,
>> etc. The Lcc32 free compiler comes with those tools already. I can imagine
>> building Euphoria coded DLLs, mixing Eu code with C/Pascal/Asm, etc.
>
>You cant compile a language meant to be interpreted.
>All 'compiling' really is, is do some/a lot/huge amount of optimization at
the cost of 'compile-time'.
>Take the JIT-technology for Java, is it interpreted or compiled ? Hard to
tell.
>What you want is a way to effectively communicate in *any* or (preferably)
*all* ways.
I know it makes little sense building such a compiler if it were for speed.
But the power of mixing and combinig Euphoria with other tools/languages
makes it very, very interesting. I also remember Rob curriculum said that
he worked many years developing compilers... he must have some expierience
with code generation ;)
>I am in favor of being able to bind to a DLL. Off course we would need a
new procedure which we use to define the exact
>arguments and pointers/value issues. (if structures and arrays were
available btw, the pointer/value issue would be even less of
>a problem)
>I'm under the impression though, that object and library files are
compiler dependant and exist in many flavors, but I might be
>wrong. (let's hope so)
I think you are wrong (but not sure). I know that Borland's libs and
Microsft's are supposed to be incompatible, but have never heard of
compatibility problems with OBJs. If we could have OBJ output of our
Euphoria code we would also need an RTL (mainly the sequence engine and
garbage collector), these are usually distributed as libs, but a bunch of
objs would work fine. A couple of make files for popular tools (Watcom C++,
VC++, Borland C++, etc..) and we are ready. The linker will then make your
EXE or DLL. Cool!
Another alternative would be to generate ASM code, the developer compiles
it with it's favorite assembler (NASM comes to mind,
http://www.web-sites.co.uk/nasm/) and then links it with the RTL OBJs.
One little thing: It should only be for Win32 (and Linux), I belive
distribution of CAUSEWAY as OBJ would be against their license. Unless RDS
change Causeway for freely distributable dos extender (like WDOSX,
http://www.geocities.com/SiliconValley/Park/4493, works with Watcom).
Regards,
Daniel Berstein
[ daber at pair.com ]
14. Re: Multi-Platform Support
Daniel Berstein writes:
> I assume the file size of the interpreter is hardcoded onto the exe,
> and that screw things when you pack it.
That's right.
You haven't said *why* you want to pack exw.exe.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
15. Re: Multi-Platform Support
Bernie Ryan writes:
> If Euphoria uses the flat address model then can you tell me what
> segment address it uses ?
If you trace execution of demo\dos32\hardint.ex you will see what the
code and data segments are. I think they may be different from
run to run, and I think they are different from each other,
although they *map* to the *same* physical memory.
On the 386 and up, running in 32-bit mode, a full machine
address is 48 bits:
16 bit segment number + 32-bit offset within that segment
In general, only the operating system cares about the
segment number. With the 32-bit flat address model used by Euphoria,
it is *rarely* of any importance to your program what these
segment values are, even when you are mucking about
at the machine level with peeks/pokes etc.
99.9% of the time all you care about is the 32-bit *offset* part of
an address. In ancient 16-bit machine-level programming, you
are constantly dealing with segment numbers, because a segment
can only contain 64K bytes, so any large program *must* use
many segments. This was a pain. You do not have to worry about
it anymore when you are working with *one* huge segment of
4Giga bytes.
Euphoria (actually Causeway) arranges for low 32-bit memory
addresses to map into the 0..640K conventional memory range
without any need for old-style 16-bit segments and 16-bit offsets.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
16. Re: Multi-Platform Support
At 04:39 PM 14-03-1999 , you wrote:
>Daniel Berstein writes:
>> I assume the file size of the interpreter is hardcoded onto the exe,
>> and that screw things when you pack it.
>
>That's right.
>
>You haven't said *why* you want to pack exw.exe.
Sometimes a 145K+ program to perform a simple task seems superflous to me.
Put many of these small (in complexity) utilities together and you get
lot's of wasted disk/bandwith. Another benefit of exe packing is automatic
CRC checking (virus protection) and protection from reverse engeneering.
What do you think of the append_resource thingy?
If a simple change can provide lower system resources usage, program
security and flexibility to the developer, why don't put it?
BTW ASPack compresses exw.exe to 68.5K.
Regards,
Daniel Berstein
[ daber at pair.com ]
17. Re: Multi-Platform Support
Bernie wrote:
> If Euphoria uses the flat address model then can you tell me what
> segment address it uses ? Also if I allocate_low some bytes what
> segment address this uses. If these are always the same then
> why isn't there a CONSTANT for these magic numbers in Euphoria.
> All I want is:
> An allocate_low function to return a sequence with { segment, offset }
Here:
function alloc_low(atom amount)
-- allocates some amount of low memory and returns { segment, offset }
atom lmem
lmem = allocate_low(amount)
return { floor(lmem / #10000), and_bits(lmem, #FFFF) }
end function
> A match function that searchs for a BINARY sequence in a memory block
Use the Euphoria match function, but peek out the memory block first:
match(some_seq, peek({some_mem, mem_size}))
Later,
_______ ______ _______ ______
[ _ \[ _ ][ _ _ ][ _ ]
[/| [_] |[/| [_\][/ | | \][/| [_\]
| ___/ | _] | | | _]
[\| [/] [\| [_/] [\| |/] [\| [_/]
[_____] [______] [_____] [______]
xseal at harborside.com ICQ:13466657
http://www.harborside.com/home/x/xseal/euphoria/
Linux + GNOME = Windows++++
18. Re: Multi-Platform Support
Thanks Pete
I didn't think of using match in that way.
Thats what I wanted.
Bernie
