1. Support for older Euphoria programs? And porting DOS->Windows?
- Posted by silverblade Apr 18, 2011
- 2423 views
Hi, I used to use Euphoria quite a lot - quite strange to think it was actually about 10 years ago that I wrote my last Euphoria-based program!
Anyway the main thing I worked on was a DOS-based MIDI music sequencer, with the UI of a tracker. This worked nicely as my main music-creating program for a good couple of years, but it was DOS-based and had a few limitations.
Now, I would be keen to somehow port this to Windows, I am not too bothered about changing how it looks but I certainly can no longer poke data at the hardware ports.
I started coding a library in C which would provide a virtual screen (though the program relies heavily on text, it does do some drawing too), and have made a few routines that would get called instead of the built-in or default library routines and so far it seems to work well - against the latest Euphoria 3. Ultimately I'd hope it could function as an aid to porting DOS-based Euphoria programs over to Windows. But more than anything, I'm just finding it interesting to do.
So I am wondering just how compatible Euphoria 4 is with older programs (code-wise)? My main concern is the include files, since what I have done is create my own "graphics.e" for example, which gets included instead of the standard one. But from looking in the manual, this now lives in std/graphics.e ?
EDIT: Just downloaded/installed Euphoria 4, as far as I can see it requires minimal changes. Only difference I have found so far is that I need to explicitly state "override" on the built-ins I'm replacing.
2. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by SDPringle Apr 18, 2011
- 2401 views
The new graphics.e and std/graphics.e are minimal compared to its DOS32 cousin. If you want to create a wrapper between win32lib, and all of those graphics routines used to do, I'll give you what I started. I never got around to finishing it. If you only do text-based console graphics, it seems that what is still left will be enough.
Shawn
3. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Insolor Apr 19, 2011
- 2393 views
Have a look at the http://rapideuphoria.com/dosrescue2.zip
It is a library for porting dos->windows. It is stable now but it is not complete yet.
4. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by silverblade Apr 19, 2011
- 2313 views
Ah so it seems someone else has already had similar ideas - always seems to be the way it goes! ;)
Some useful stuff in there. I'll probably continue with mine, at least as a personal project if nothing else.
5. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by SDPringle Apr 20, 2011
- 2264 views
Insolar's library is 3.1 and in 4.0 when overriding you'll have to use namespaces when a program calls the old version of a routine.
For example:
These lines of code will call your new version of 'gets'.
-- global function eu_gets(integer fn) return gets(fn) end function
This routine is called by the new 'gets' as well. You end up with infinite recursion.
It would also be better if you use std/*.e includes rather than *.e because that way you can get around DEP proection on memory allocated with allocate and legacy apps often run code from memory returned from allocate.
Shawn Pringle
6. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Vinoba Apr 20, 2011
- 2235 views
Insolar's library is 3.1 and in 4.0 when overriding you'll have to use namespaces when a program calls the old version of a routine.
Shawn Pringle
It is understandable that a verb in English can be used with different meanings in different functions, and therefore namespaces are needed to overcome this difficulty. However, since euphoria 4.0 should (hopefully) try to accept code written for 3.1,
1. should not there have been an attempt to coin different verbs to accommodate everything without namespaces?
2. Or to put it in a technical perspective, is there any other SUBSTANTIAL ADVANTAGE in having namespaces within euphoria as it is today?
3. And again speaking purely technically, if the need for namespaces can be justified on grounds of "SUBSTANTIAL ADVANTAGE", is there need for some 60 namespaces as they exist now in version 4? Would not 8-10 namespaces suffice? After all, looking at the history of euphoria from the days of 1 megabyte computers to 3GB and more now, there ought to be enough memory there to accommodate everything in much fewer namespaces, if such are needed.
7. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Insolor Apr 20, 2011
- 2227 views
Insolar's library is 3.1 and in 4.0 when overriding you'll have to use namespaces when a program calls the old version of a routine.
For example:
These lines of code will call your new version of 'gets'.
-- global function eu_gets(integer fn) return gets(fn) end function
This routine is called by the new 'gets' as well. You end up with infinite recursion.
Shawn Pringle
I was confused slightly, so I had to consult with the docs:
If an identifier is declared global, public or export, but not override, and there is a built-in of the same name, Euphoria will not assume an override, and will choose the built-in. A warning will be generated whenever this happens.
Therefore given routine will call built in puts instead of newly declared one. Furthermore I checked this by the eui and the following code didn't cause an infinite recursion:
include dos_rescue.ew as dos_rescue dos_rescue:puts(2,"Hello!")
I was intended to make dos_rescue both eu3 and eu4 compatible, but now I am thinking of separating eu3 and eu4 versions of the library.
8. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by SDPringle Apr 20, 2011
- 2207 views
I have just ported this to 4.0. I didn't modify the program files themselves. It seems possible to have distinct include directories in 3.1 and 4.0 without changing environment variables. eu.cfg can contain a directory pointing to these version 4 libraries and in EUINC version 3 libraries. The old EUPHORIA will ignore eu.cfg. Check if the EU 4, uses eu.cfg before EUINC.
Shawn
Forked into: dos_rescue2: Port patches for 3.1 projects 4.0
9. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Insolor Apr 21, 2011
- 2218 views
I have just ported this to 4.0. I didn't modify the program files themselves. It seems possible to have distinct include directories in 3.1 and 4.0 without changing environment variables. eu.cfg can contain a directory pointing to these version 4 libraries and in EUINC version 3 libraries. The old EUPHORIA will ignore eu.cfg. Check if the EU 4, uses eu.cfg before EUINC.
Shawn
Yes, I have both versions (3.1 and 4.0) of the Euphoria on my machine, and they take include files from the different directories because eu4 uses eu.cfg before euinc.
I used *.e includes instead of std/*.e ones because I wanted to make dos_rescue independent on what did it run with, exw or euiw. Though may be some day I will make different versions of the library, one for the Euphoria 3.1 and another for the Euphoria 4.0.
10. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by mattlewis (admin) Apr 21, 2011
- 2141 views
It is understandable that a verb in English can be used with different meanings in different functions, and therefore namespaces are needed to overcome this difficulty. However, since euphoria 4.0 should (hopefully) try to accept code written for 3.1,
Mostly, 3.1 code will run with 4.0. There are a few gotchas, mostly with respect to some new keywords. Also, of course, 4.0 no longer supports DOS.
1. should not there have been an attempt to coin different verbs to accommodate everything without namespaces?
2. Or to put it in a technical perspective, is there any other SUBSTANTIAL ADVANTAGE in having namespaces within euphoria as it is today?
I think this would have been a bad idea. We would have ended up with lots of similarly named, but very different functions. The real choice was between prefixing routines vs using namespaces. With prefixes, you really have to prefix absolutely everything or nothing. Otherwise you end up with lots of inconsistency, and things just get more awkward as the library grows.
Having the same name for the same operation, but on a different data structure, etc, is actually fairly convenient. I suspect (though I haven't explicitly counted) that the most common shared name is new() (syntax coloring, maps, stacks, regexes and date times). The only way to get around that would be to prefix or suffix with the object (new_map, regex_new, etc).
3. And again speaking purely technically, if the need for namespaces can be justified on grounds of "SUBSTANTIAL ADVANTAGE", is there need for some 60 namespaces as they exist now in version 4? Would not 8-10 namespaces suffice? After all, looking at the history of euphoria from the days of 1 megabyte computers to 3GB and more now, there ought to be enough memory there to accommodate everything in much fewer namespaces, if such are needed.
What's the advantage of having fewer namespaces? Basically, each file has its own default namespace, and each file contains routines that are all related somehow (regex, math, files, etc). I'm not sure I understand why having fewer namespaces would be a good thing. One big reason for so many default namespaces (and the ability to declare a default namespace is new to 4.0) is mainly that there is a lot more in the 4.0 standard library than in 3.1.
At a lower level, a namespace is simply another symbol in the symbol table, which has its own scope, and which points to a particular file. It does not consume much in the way of resources.
Matt
11. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Vinoba Apr 21, 2011
- 2073 views
Thanks for the detailed reply.
I like the idea of the same function name applied to many different types.
12. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by SDPringle May 03, 2011
- 1886 views
I checked out the new version of dosrescue 3. It works fine under EUPHORIA 4. There is much better color handling now. Isolar, why did you mark sound() as a stub. It does everything the DOS version did. Once everything is implemented, we could rename this to graphics.e and use as a dropin replacement for the said file.
13. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Insolor May 03, 2011
- 1851 views
Isolar, why did you mark sound() as a stub. It does everything the DOS version did.
sound() is not a stub, but it works different from it's DOS equivalent. Try this code with dos_rescue and dos32:
-- include dos_rescue.ew -- uncomment it for Win32 -- include graphics.e -- uncomment it for DOS sound(1000) for i = 1 to 1000000000 do end for sound(0)
DOS version of the given procedure will produce very long beep, while the version form the dosrescue will produce single short beep. I have no ideas how to make them work alike.
Now I have made few more bug fixes and improvements (such as optimized scroll() that works fine even on an old 1.66 MHz machine), so I will upload the newer version of the library soon.
14. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by SDPringle May 04, 2011
- 1794 views
Why don't we use email? It will be faster to email versions than to upload them.
15. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Insolor May 04, 2011
- 1777 views
Why don't we use email? It will be faster to email versions than to upload them.
Why not? My email is inside of readme.txt in the dosrescue2.zip
16. Re: Support for older Euphoria programs? And porting DOS->Windows?
- Posted by Insolor Sep 15, 2012
- 1418 views
After long pause, I am raising the topic again. Lately I've made some changes to dos_rescue:
- First of all I've stopped Euphoria 3 support. I cosidered that on the one hand for now Eu4 is reliable enough, and on the other hand Eu3 don't need dos32 emulation because it supports dos32 itself. So now we can use overrided eu routines without putting dos_rescue qualifier before them.
- I made the window border resizable and made the image scaleable by integer factor.
- Now you can toggle the full screen mode by pressing Alt+Enter or with some routines like set_full_screen(on_off)
In the future:
- I plan to add 24-bit color support
- Use the mutithreading instead eu tasking in order to make the window active during long loops like
for i=1 to 1e6 do something_without_yielding_task() end for
You can get the code of dos_rescue here: https://bitbucket.org/insolor/dos_rescue
I haven't put anything at the downloads tab yet, but you can get the package by pressing 'get sources' button (white sheet of paper with blue down arrow).
As for https://bitbucket.org/mattlewis/dos_rescue I can't do much for it because I am not familiar with the X library.
Forked into: dos rescue graphics library
