OpenEuphoria

2. Re: Version 4.1.4b No Longer Supports Dos

• Posted by useless Sep 23, 2010
• 7789 views

It's my understanding some long-time bugs in v3 were fixed in the early v4 before dos was dropped, or maybe after dos was dropped. Is it faintly possible to back track only the bug fixes (memory leaks, whatever) to the last v4 that did run ok on dos? Maybe it wasn't even called v4 at the time, i forget.

And maybe a few of the long-sought new features? Like the one Derek fixed last week, the "release all file handles when the app is terminated and before the interpreter pops up error msgs"?

This wouldn't be a version supported in the future, it would be only a bug-fixed, slightly improved v3, maybe v4.0.0.0.1?

useless

4. Re: Open Call for DOS Developers

• Posted by useless Dec 07, 2010
• 7566 views

But you guys convinced me that i am useless. I finally believe you.

useless

6. Re: Open Call for DOS Developers

• Posted by useless Dec 07, 2010
• 7558 views

I believe that is a true statement. You have not addressed me as the nick "useless". Likewise, i have not addressed you as "TerrificProgrammer", yet we remain these things.

useless

8. Re: Open Call for DOS Developers

• Posted by jimcbrown (admin) Dec 07, 2010
• 7522 views

HI Kat 
The last version of ver4 that supported DOS that I 
know was working was SVN1705 . 
 
That was the version before Jeremy decided to change 
names of interpreter binaries. 
 
The names were still exw.exe ex.exe at that point. 
 
Versions after the names were changed became all messed up 
and I couldn't build anything  for DOS after that worked. 
 
Soon after that DOS was dropped. 

The last eubin with DOS support was r2434 which had euid.exe and is available for a limited time from http://jeremy.cowgar.com/eubins/windows/eu40-2434.zip

At some point perhaps shortly after the name change, ShawnPringleBSC changed makefile.wat to use eui.exe to build euid.exe - this change was to allow Jeremy to build the DOS eubin on Windows 7 but broke the makefile for anyone who tried to build Euphoria on DOS alone.

I did hear back from one person who expressed, uh, enthusiasm at reviving the DOS port. I haven't heard back from this person since Sunday but maybe has only weekend availablity.

10. Re: Open Call for DOS Developers

• Posted by jimcbrown (admin) Apr 12, 2013
• 7079 views

The one (rather insulting) person who seemed interested disappeared after the one day. That was over two years ago.

12. Re: Open Call for DOS Developers

• Posted by jimcbrown (admin) Apr 17, 2013
• 6743 views

Thank you again for doing that.

It looks like that person was the rather irritating guy I talked to on IRC.

If http://www.bttr-software.de/forum/mix_entry.php?id=9244 is accurate, then all the issues encountered were really trivial ones (configure.bat needs some fixes to run with command.com instead of cmd.exe, someone needs to provide pre-translated sources for a --without-euphoria DOS build, perhaps some minor makefile.wat changes to make sure we only build the docs and so on after we've built a new source binary, etc).

If someone sent me a copy of the list of build errors and errors running configure.bat on command.com, I could probably make the relevant changes myself. I wish that Rugxulo had returned to the IRC channel when these issues were encountered so I could help fix it, though I understand having a lack of spare time to dedicate to such an endeavour.

(As an aside, I always found it ironic that Shawn Pringle fought to keep DOS support in the end when he helped kill it in the first place (by breaking the build for DOS-only users when he rewrote the makefile to use exw.exe to build ex.exe,trying to solve a problem that I had already solved before).)

On the back burner, if there was no interest in reviving a full MSDOS port of Euphoria, I had on the back burner a plan to create a DJGPP only "UDOS" port, which would levage DJGPP's POSIX compatibility and provide limited to no support for the DOS specific stuff (graphics, allocate_low, dos_interrupt, etc), instead requiring users to write their own machine code and use call() to implement those features. I figure that this should require only minimal changes to current pre-4.1 sources.

The reason that we chose not to keep a build for DOS going was because the amount of code in Euphoria to support DOS, which was never used in any other platform, was extensive (Jeremy said it was a huge percentage of Euphoria's overall code line count at the time, he had a specific number but I can't recall what it was at the time). That was a huge amount of dead code to allow to bitrot. I guess we could have kept a minimalist infrastructure for DOS going though, stripping that out but leaving behind the #ifdefs so a DOS build would still be possible instead of removing everything.

Someone here claimed that we should drop DOS due to a lack of interest in it, but in the same thread, Arjay claims that there may not be enough interest in Euphoria to support a DOS port revival. (If the HX DOS Extender works for Cygwin's gcc, it'd probably just work for eui.exe as well.)

14. Re: Open Call for DOS Developers

• Posted by jimcbrown (admin) Apr 17, 2013
• 6634 views

I contend that this is not libel because 1) it is true, as you admit below, and 2) it does not do offense to your character (you were, after all, trying to improve the quality of eubins, which I find a notable goal).

Agreed.

What I disagree with here is that you made this change unilaterally, without discussing the merits of it on the dev list or the forum, which meant that there was no way to suggest alternatives or improvements (such as including a special target that unconditionally used ex.exe so DOS users could keep building, or a special eubins-DOS target that only the eubins server and other windoze 7 users would have needed to invoke). Instead I didn't realize that this had been changed until many months after the fact.

My understanding was that you made this logical change due to be able to build the dos binaries on a windows 7 system. I have no objection to that on principle, but we had a workaround (EUDOS) that allowed building the DOS binaries using ex.exe on Windoze 7, so this was (at the time) unnecessary. (With the advent of Windoze 8 and the complete dropping of DOS support, this would no longer work and your change, in hindsight, was necessary.)

Also, could we really have said that we supported DOS back then, if a DOS user could not build Euphoria out of the box but had to engage in Makefile hacking first?

Agreed.

A shame then, that the DOS branch apparently doesn't even build out of the box now.

But yes, I agree with you here.

I don't understand this. How can you directly call malloc() from a batch file? Or even a shell script????

We have align4 code as part of managed memory. That should have taken care of this.

I was under the impression that a) if you build the binaries yourself, you just had to configure with --align4 to enable this, and b) all the official releases were suppose to be built with ALIGN4 on for the 9x users. (I also recall Derek's strong disagreement with this when we did one of the releases and his refusal to ever build a binary with align4 support.)

Can you identify when align4 support was removed? I just checked trunk and it looks like it's still in there.

16. Re: Open Call for DOS Developers

• Posted by jimcbrown (admin) Apr 17, 2013
• 6583 views

Rugxulo

18. Re: E-waste

• Posted by jimcbrown (admin) Apr 17, 2013
• 6587 views

Agreed in full.

Can you provide a list of what was released that was built without align4? I'll see if I can track down the distributor and get it fixed. (Yes, we may have to rerelease a bunch of old releases. That's worth it imvho.)

Again, agreed, it should be the default. I don't recall now why it isn't the default. I'll change this if there are no objections.

Of course, it's possible that, even if it's still in there, it became broken at some point. It's not enough to have the code in there to bitrot, we need active 9x testers to make sure that it's still working. At this point, I'm not sure that we have any.

That's the real problem.

20. Re: E-waste

• Posted by ne1uno Apr 17, 2013
• 6553 views

I don't recall the default ALIGN4 ever being changed. managed memory is the default for windows. minGW build always shows system memory no matter what, and there is no indication in any header or info that outputs build properties. might be nice, probably easy but noone has done the few tweaks and tests to make it happen. would be good to embed more of the build info too, which compiler,version etc.

euphoria should still run on win98SE out of the box. would still run on win95 if internet explorer 4 was installed. in the States, millions of ISP cd's were given away and junk mailed out for years with Internet Explorer and Dun installer. I still have a few kicking around if anyone wanted a zip to try. might be difficult to download from any official channel these days. I think even oldapps links to microsoft.

this is only required because sockets are now builtin. it wouldn't take much to ifdef that into an option apparently just making it lazy loading wasn't enough and I think Shawn could better say what the exact problem is.

it could be you still need IE4, 5 or 6 because of Common Controls. which can't easily be ifdef'ed around. and is standard win98 and up. I can't recall the last time I tried on win98 or win95 though. and it's been years since anyone asked.

22. Re: E-waste

• Posted by irv May 03, 2013
• 5472 views

I'm curious to see if anyone has a valid reason why anyone should devote time to adding DOS support.

As far as I can tell, there's not a lot of enthusiasm for programming *any* platform anymore, except for phones and tablets. IOW, computer programming is quickly going the way of "fixing your own car". In addition, I suspect that any old 'stuck in the mud' folks like me who actually know what a 'terminal' is and aren't afraid to use it have been using Linux for years now.

And if Euphoria did indeed run on DOS, where are you going to find anyone who has the hardware, or who would be willing to use your program? Outside of a computing museum, that is. Remember, when DOS was the only thing available, most users complained about how clunky and difficult to use it was, which was the impetus for the invention of the GUI.

24. Re: E-waste

• Posted by useless_ May 03, 2013
• 5402 views

I've been using win-xp for 10+ years, but hardly a day goes by i don't open a doxbox or write a batch file.

useless

26. Re: E-waste

• Posted by useless_ May 03, 2013
• 5424 views

And yet, if the dosbox or the batch file was moved over to a 80286 DOS5 computer, it would still run the same. Likewise, if someone put a DOS version on their 3Ghz P4 i'd expect it to also run the same.

Imo, dos's biggest issue was it's lack of modern filesystems and wider bit-widths and non-re-entrancy. Replace winxp's gui with a dos-lookalike written in Euphoria, i'd be happy with it, and i'd use it like i use the dosboxes now. There's one open now, there were three this morning, no doubt i'll pop open more as the day goes along.

I am using "dos" to refer to the look and feel, not to 15 year-old 16bit code.

useless

28. Re: E-waste

• Posted by jimcbrown (admin) May 03, 2013
• 5380 views

This is almost certainly correct in your case, but in general I'll contend that it's not true. cmd.exe adds many new features that aren't compatible with older versions of COMMAND.COM (though 4DOS typically supports these), and unless you know what you are doing and are careful to avoid it, it's possible nowadays to write a batch script that unintentionally will only run with cmd.exe (later versions of Euphoria's own configure.bat being an example, according to a FreeDOS thread).

Agreed. If nothing else, there's NTFSDOS. DrDOS came out with a 32bit pre-emptive version at one point in time. I'm not sure if FreeDOS has completely caught up yet, but it has an active community so I figure it is only a matter of time.

30. Re: E-waste

• Posted by andi49 May 03, 2013
• 5410 views

Hallo

Powershell 2.0

http://www.chip.de/downloads/c1_downloads_hs_getfile_v1_29374285.html?t=1367618666&v=3600&s=a9adf08a825b484afadabab6cd28f839

It's a downloadpage from a German Computer Magazine.Worked a few minutes ago ;)

Andreas

32. Re: E-waste

• Posted by useless_ May 03, 2013
• 5442 views

That url forwards me to http://www.chip.de/downloads/Windows-PowerShell_29374274.html and there is no powershell download on that page. I mean, there is a "Zum Downloads" button, but it simply refreshes http://www.chip.de/downloads/Windows-PowerShell_29374274.html, there is no download.

Using wget, i finally found http://dl.cdn.chip.de/downloads/4430736/PowerShell_Setup_x86_3.msi?1367622779-1367630279-b74fe9-B-6247bf783a5a9029d86cfe627f252c3c which is a 7 megabyte file.

Do i want v2 instead of v1? I did not install yet. I am not looking for a new programming language, whatever dos won't do, Euphoria does plus more. But lets face it, Eu can runtime crash 5 minutes after i goto bed, while a dos command like "type *.html >> total.htm" will keep running. So i do not want more fancy code like AutoIt, especially if having it opens security holes (you might have noticed this puter hates downloading files).

useless

34. Re: E-waste

• Posted by jimcbrown (admin) May 04, 2013
• 5348 views

That was before my time here. Still, without knowing any additional details, I want to note that there is a major difference between an OS-specific RPC (e.g. the 28-year old unix-specific http://en.wikipedia.org/wiki/Portmap ) and one designed from the ground up to be as general as possible (e.g. http://en.wikipedia.org/wiki/SOAP ).

I wonder if something like this would have helped: http://www.plop.at/en/bootmanager/usbdos.html

Yes. I was surprised that even FreeDOS lacks support for EFI! http://comments.gmane.org/gmane.comp.emulators.freedos.general/11049

I have, however, seen a few workarounds: e.g. http://randomcomputerbits.blogspot.com/2008/02/tutorial-installing-freedos-on-intel.html (But of course, researching this and getting it to work may well have taken more time than just getting a replacement disk or setting up emulation. I'm just pointing out that it's possible to do it, but just because it can be done doesn't necessarily mean that it is the best course of action.)

That's a pretty impressive accomplishment for someone who was under the age of six years old at the time.

36. Re: E-waste

• Posted by jimcbrown (admin) May 04, 2013
• 5266 views

I disagree. I'd consider it a scripting language.

bash,csh,etc. are also scripting languages. In fact, one can argue that command.com batch files are a class of scripting language as well, albeit a very primitive one.

38. Re: E-waste

• Posted by andi49 May 04, 2013
• 5239 views

I do not know if you want v1 over v2. But beginning with v2 there is powershell_ise.exe
It's a an ide for batch files (more or less).

Andreas

40. DOS 4.XXX question

• Posted by BRyan Jun 01, 2013
• 4527 views

Is there a complete 4.xxx source version containing WIN & DOS; located on a server 
where it can be downloaded for compiling with OpenWatcom. 
 
PS: Please no debates I  just want a simple answer. 

42. Re: DOS 4.XXX question

• Posted by DerekParnell (admin) Jun 01, 2013
• 4482 views

Is there a complete 4.xxx source version containing WIN & DOS; located on a server 
where it can be downloaded for compiling with OpenWatcom. 
 
PS: Please no debates I  just want a simple answer. 

No.

44. Re: DOS 4.XXX question

• Posted by BRyan Jun 01, 2013
• 4524 views

Is there a complete 4.xxx source version containing WIN & DOS; located on a server 
where it can be downloaded for compiling with OpenWatcom. 
 
PS: Please no debates I  just want a simple answer. 

Thanks Jim

46. CALL FOR DOS REVISTED

• Posted by BRyan Jun 08, 2013
• 4631 views

There is no version of dos that can be built with 4515 or 4755. 
 
There are files missing in the code. 
 
The make files are looking for msgtext.e which is missing. 
 
If you add that file from 402b then the compiler streams out SLASH not 
defined errors every where. 
 
It looks like someone was trying to add things to the source for command line stuff 
and for different OS's. 
 
What happen to the full source that was on the server prior to DOS being abandoned. 
 
I am using open-watcom on XPPro to build. 
 
Bernie 
 

48. Re: CALL FOR DOS REVISTED

• Posted by BRyan Jun 08, 2013
• 4584 views

Thanks for the information Jim
Bernie

50. Re: CALL FOR DOS REVISTED

• Posted by jimcbrown (admin) Jun 08, 2013
• 4572 views

<0074>:: Errors resolving the following references: 
	E:\EU4515\source\main.e (161): SLASH 
	E:\EU4515\source\scanner.e (487): PATHSEP 
	E:\EU4515\source\preproc.e (110): SHARED_LIB_EXT 
	E:\EU4515\include\std\cmdline.e (1029): CMD_SWITCHES 
	E:\EU4515\include\std\filesys.e (1350): SLASHES 

I have figured out what the issue here is.

In short, std/filesys.e in the DOS branch relies on the DOSFAMILY define to be defined by the interpreter, but the none of the alphas and all but one of the betas lack support for this define.

You can workaround the issue easily by manually defining it.

Open makefile.wat, and look for this section:

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 

Change it to look like this instead.

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 
RELEASE_FLAG = -D DOSFAMILY 

Alternatively, you may also be able to use 4.0b1, the beta that has DOSFAMILY, to build Windows executables from the DOS branch. Then you can use the newly built Windows executables to build the DOS version.

Here is the history of how this happened.

4.0a3, http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/tags/4.0a3/ , was released Wed Mar 11 20:39:19 2009 UTC. This was before the DOSFAMILY tag was created, and thus this and all earlier versions of Euphoria can not build the DOS branch (at least without some tweaking).

The DOSFAMILY tag was created on Wed Apr 08 18:01:56 2009 UTC, after the last alpha (and thus, barring any DOS eubins still out there, after the last version of Euphoria to support DOS). http://scm.openeuphoria.org/hg/euphoria/rev/b384407d0922

Then the DOS branch was created on Sun Aug 9 22:23:37 2009 UTC. http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria?view=revision&revision=2438

At Fri Aug 28 14:55:00 2009 UTC, DOSFAMILY was removed (as it was redundant now that we no longer had DOS). http://scm.openeuphoria.org/hg/euphoria/rev/d46f788027cf

4.0b1 ironicly still had DOSFAMILY defined when it was released in Wed Aug 12 00:47:54 2009 UTC, thought it can't build the DOS branch for DOS due to its lack of DOS support. http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria?view=revision&revision=2479

(I confirmed this by looking here: http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/tags/4.0b1/source/platform.e?revision=2479&view=markup&pathrev=2479 )

However, by 4.0b2, released Mon Aug 31 16:16:47 2009 UTC, DOSFAMILY had been removed from the release. That and all later versions of Euphoria no longer define DOSFAMILY and can not build the DOS branch without tweaking.

52. Re: CALL FOR DOS REVISTED

• Posted by jimcbrown (admin) Jun 22, 2013
• 4415 views

How did this go?

54. Re: CALL FOR DOS REVISTED

• Posted by jimcbrown (admin) Jun 22, 2013
• 4469 views

What happened when you tried this?

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 
RELEASE_FLAG = -D DOSFAMILY 

You should be able to ignore that. CMake was never the primary build system.

All the code should be in the SVN server, so we shouldn't have any lost source.

56. Re: CALL FOR DOS REVISTED

• Posted by jimcbrown (admin) Jun 22, 2013
• 4411 views

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 
RELEASE_FLAG = -D DOSFAMILY 

SVN 1705 is available from hg at http://scm.openeuphoria.org/hg/euphoria/rev/8926e37340dd or the old SVN server at http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria?view=revision&revision=1705

The latest is only available from hg, http://scm.openeuphoria.org/hg/euphoria/rev/bdcbd57525de

There's list of changes from hg at http://scm.openeuphoria.org/hg/euphoria/shortlog/bdcbd57525de

There's also a list of changes from svn at http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/trunk/?view=log

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 

!ifeq RELEASE 1 
RELEASE_FLAG = -D EU_FULL_RELEASE 
!endif 
RELEASE_FLAG = -D DOSFAMILY 

58. Re: CALL FOR DOS REVISTED

• Posted by jimcbrown (admin) Jun 22, 2013
• 4404 views

Can you show me the complete contents of your modified makefile.wat ?

Another thing to try is to edit std/filesys.e and replace all references to DOSFAMILY with DOS or MICROSOFT. But you may end up having to modify a lot of files if this is the case. (This is really easy to do on nix though - just use sed.)

That shouldn't matter unless we're cross-translating.

60. Re: DOS source ?

• Posted by jimcbrown (admin) Jun 30, 2013
• 4497 views

I wrote it. The idea is that we have one big file, be_callback.c, that defines all the possible call_back options, however typing all of that out by hand was very tedious, so I wrote a helper script, make_be_callback.ex, to save some effort.

The idea was that, I'd run make_be_callback.ex once, commit the source, and that was it. You shouldn't ever need to run make_be_callback.ex ever again...

This was originally designed for OSX. I forgot about the DOS/Watcom limit on a file size. You should be able to make this work if you modify make_be_callback.ex to write out the code into multiple files instead of one file.

62. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 02, 2013
• 4812 views

I am very disappointed to hear this.

We have everything except for the binaries. The original archive of source code exists.

I know how the code was suppose to work. If you have any questions, just ask me.

I don't understand this. If nothing else, you could have just removed the ifdefs entirely...

It is true that our approach is not identical to Rob's. However, I believe that the reason that the current DOS branch is unrelated.

I now believe that, although we officially supported DOS at that time, the SVN code had in fact been broken with regards to DOS support for a very long time. I think this validates the decision to drop DOS support - the code must have bitrotted for a very long time.

Why is this relevant? What are you trying to do here? platform for what? Euphoria itself?

64. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 02, 2013
• 4827 views

I just tried this and I was able to build eui, euiw, euc, eub, and euid.

In addition to adding msgtext.e, I had to add euphoria.h from http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/trunk/include/euphoria.h?revision=2428

Also, the instructions to modify makefile.wat in http://openeuphoria.org/forum/m/121960.wc are not enough. I had to add it to EUDEBUG as well as manually adding that flag to a variety of places where the interpreter is invoked (e.g. findjmp.ex or revget.ex).

Then, I modified make_be_callback.ex to set TOTAL to 20 instead of 1000 (to avoid the DOS max c file size limit) and generated be_callback.c

Next, the be_callc.c code I had for DOS did not work (since it was derived from a later version of the source). I fixed this up.

Finally I changed line 4540 of be_machine.c from "else {" to "} else {".

I seem to be locked out of my SVN account for the time being, so I can't commit these changes. Instead, I'll put up some links.

Here is a big diff of all the changes that I made:

http://openeuphoria.org/eubins/misc/dos.diff

Here are the individual files for download (not including euphoria.h or msgtext.e):

http://openeuphoria.org/eubins/misc/eu40dos.tar

66. Re: dos is a lost cause !

• Posted by BRyan Jul 03, 2013
• 4609 views

Jim: 
 
The links have Forbidden excess. 
 

68. Re: dos is a lost cause !

• Posted by BRyan Jul 03, 2013
• 4604 views

I downloaded this file but I don't know what it is used for ? 
 
It is not a zip file ? 

70. Re: dos is a lost cause !

• Posted by BRyan Jul 03, 2013
• 4605 views

ok  
Thanks I will get back to you later. 
 
I have to attend to some other things. 
 

72. Re: dos is a lost cause !

• Posted by BRyan Jul 03, 2013
• 4693 views

Jim: 
 
The euid.bin file must be corrupted if I rename it and run it 
I get the following error : 
 
Critical Error: Abort, Retry, Ignore, Fail?  
 
 
If I do a wmake winall I get the following error : 
 
 
F:\EUDOS\source\traninit.e:136 
<0074>:: Errors resolving the following references: 
	'replace_all' (..\..\parser.e:4356) has not been declared. 
	'get_text' (..\..\msgtext.e:347) has not been declared. 
	'SUNOS' (..\..\platform.e:19) has not been declared. 
	'DOS32' (..\..\platform.e:103) has not been declared. 
	'DOS32' (..\..\traninit.e:136) has not been declared. 
 
						set_host_platform( DOS32 ) 
						                         ^ 
 
 
--- Defined Words --- 
EU4 
EU4_0 
EU4_0_5 
WINDOWS 
WIN32 
CONSOLE 
DOSFAMILY 
E32 
EUI 
------------------- 
 

74. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 03, 2013
• 4598 views

dos trunk.

I never sent you a msgtext.e

You should be using http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/trunk/source/msgtext.e?revision=2428 and http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/trunk/include/euphoria.h?revision=2428

That version of msgtext.e is designed to use the version of get_text() in std/text.e here: http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/trunk/include/std/text.e?revision=2428

However, the DOS trunk version also has this function: http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/dos/trunk/include/std/text.e

I can't reproduce this error. The fact that DOS32 isn't defined leads me to believe that you've mixed up your sources and have some post-DOS-remove code in your working copy that you are trying to build with.

I'll email it to you directly, using the email address that you registered your forum account with.

76. Re: dos is a lost cause !

• Posted by BRyan Jul 04, 2013
• 4541 views

Jim: 
 
I wiped out all my dos files and got a fresh source copy from dos trunk. 
 
I replaced the 4 files and added msgtext.e to the source directory. 
 
I created the be_callback.c file 
 
I ran configure.bat 
 
I am using bins from 4.0.5 
 
I ran wmake winall and the error I get is the following: 
 

del /Q F:\EUDOS\source\BUILD\intobj\*.* 
cd  F:\EUDOS\source\BUILD\intobj 
F:\EUDOS\BIN\eui.exe -i F:\EUDOS\include -d DOSFAMILY F:\EUDOS\source\ec.ex   -d 
 DOSFAMILY -nobuild -wat -plat WIN -d DOSFAMILY -D EU_MANAGED_MEM  -i F:\EUDOS\i 
nclude F:\EUDOS\source\int.ex 
Translating code, pass: 1 2 3 4 5 6 7 8 9 10 
F:\EUDOS\source\c_out.e:206 in procedure adjust_indent_before() 
type_check failure, c (from inlined routine 'c_putc' at 141) is {} 
 
... called from F:\EUDOS\source\c_decl.e:609 in procedure c_stmt() 
 
... called from F:\EUDOS\source\c_decl.e:667 in procedure c_stmt0() 
 
... called from F:\EUDOS\source\compile.e:7073 in procedure BackEnd() 
 
... called from F:\EUDOS\source\mode.e:49 in procedure BackEnd() 
 
... called from F:\EUDOS\source\main.e:191 in procedure main() 
 
... called from F:\EUDOS\source\main.e:205 
 
--> See ex.err 
Error(E42): Last command making (F:\EUDOS\source\BUILD\intobj\main-.c) returned 
a bad status 
Should this file be deleted [Yes/No] ? 

78. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 04, 2013
• 4504 views

So far, so good.

I haven't tried that. Not sure what will happen .. 4.0.5 doesn't support building DOS binaries.

Hmm. I wonder why I hadn't seen that error before.

DerekParnell is responsible for breaking this.

http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/trunk/source/c_out.e?r1=2375&r2=2386

Anyways, change that line from c_putc to c_puts (with an s at the end).

80. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 04, 2013
• 4450 views

That line is simply

if (addr != NULL) free((char *)addr); 

I have no idea why you are getting this. Perhaps your watcom settings are set to be more pedantic than mine? Perhaps your watcom wants:

if ((char*)addr != NULL) free((char *)addr); 

Or

if ((void*)addr != NULL) free((void*)addr); 

Or

if (addr != (unsigned)NULL) free((char *)addr); 

But I really have no idea why your Watcom is being so pedantic or what it wants. (This was a great reason to drop Watcom support altogether imnsho.)

This is a really bad idea, but for now just comment out that line and the line above it.

82. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 04, 2013
• 4434 views

I see... But that worked for me on my OpenWatcom. Fickle...

be_rev.c should contain something like this:

extern char* get_svn_revision(); 
 
char * get_svn_revision() { 
        return "4745:4754M"; 
} 

If you create it by hand manually, that should be good enough to get the build going.

The -1 implies that revget.ex failed to read your .svn/entries file directly (which makes sense considering that it only supports svn 1.3 and 1.4), and it failed to run the svnversion command for some reason.

84. Re: dos is a lost cause !

• Posted by BRyan Jul 04, 2013
• 4454 views

Jim: 
 
I have successfully built the DOS32 files. 
 
What about the DOS include files there not in the dos trunk should I just use the 3.11 versions ? 
 
What about eushroud.exe where is that built ? 
 
 
Do you need any other information ? 
 
I will check back with you in about an hour. 
 
Thanks for your help. 
 

86. Re: dos is a lost cause !

• Posted by BRyan Jul 04, 2013
• 4420 views

The DOS trunk base include directory contains : 
STD      (directory) 
EUPHORIA (directory) 
euphoria.h 
 
I put the 3.11 include files here. 
 

88. Re: dos is a lost cause !

• Posted by BRyan Jul 04, 2013
• 4444 views

Just don't give Derek his pay check. 
 
Jim if DOS is working why is eui.exe needed ? 
 
The demos are messed up because some are written with the exd extent and they are 
looking for include older files with the ex extent. 
 
net include directory is missing. 
 
I think what happened with the demos is that they were rewritten for the DOS emulator  
and that the users were try to change them for dos rescue. 
 
Most of the demos were originally written for 3.11 and 
 
I see no reason for 3.11 demos not to work.  
 
The other advantage of using euid.exe is the older code in archive would work.  
 

90. Re: dos is a lost cause !

• Posted by BRyan Jul 04, 2013
• 4438 views

Jim: 
 
ex.exe was renamed by Jeremy to eui.exe 
 
Wasn't eui.exe suppose be used to run dos code until dos was removed from the source ? 
 
If we now have euid.exe can't it be used in place eui.exe 
 
 
 
When you run one of demos it is looking for net directory. 
  
 
A lot of demos use machine.e whenever it is used by a program and the program ends; 
It displays a warning that check_calls was not used. 
 
I quickly tried all demos included in 3.11 an 90% of them work with euid.exe there is 
a problem callmach.ex cw crashs but the callmach demo in 4.xx works ok. 
 
 

92. Re: dos is a lost cause !

• Posted by BRyan Jul 04, 2013
• 4378 views

Which demo? Only the demos in the net directory should be using that stuff. None of the demos that use it would be able to run with euid.exe anyways, as euid.exe does not support any networking.

The demo was httpd.ex 
 
 
All the demos in the DOS branch should be using std/machine.e - not the 3.11 version. 
If the demos use the one in std/machine.e then every time you use older code you will 
have edit the code. I put the 3.11 include files in the same place where 3.11 code 
expects them. 
 

94. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 04, 2013
• 4345 views

This looks like it was a case of a misplaced demo. It has since been fixed in the active branches.

But they are 4.xx demos. 4.xx demos should use 4.xx includes, and 3.11 demos should use 3.11 includes.

Agreed. These should be there.

96. Re: dos is a lost cause !

• Posted by DerekParnell (admin) Jul 05, 2013
• 4328 views

What I'm very unsure of is why would someone need a version of Euphoria that runs under MS-DOS? Are there still enough MS-DOS machines out there to make it worth while?

98. Re: dos is a lost cause !

• Posted by DerekParnell (admin) Jul 05, 2013
• 4277 views

My question still stands. I know that MS-DOS, FreeDOS, 4DOS, etc ... exist, but are they actually being used in any quantities that would make supporting a version of Euphoria for them worth while?

100. Re: dos is a lost cause !

• Posted by useless_ Jul 05, 2013
• 4311 views

Let me toss this out there again: Once compiled, why would Eu need an OS? On a computer that does have an OS, change all OS calls into BIOS calls, then compile the result, and load it appropriately onto the harddive and tweak the boot sector to point to it. Options could include searching for compiled .e files to merge at boot time so everyone could add EUOS extenders (nod to http://jjprog.tripod.com/euos.html ).

useless

102. Re: dos is a lost cause !

• Posted by kinzz Jul 05, 2013
• 4379 views

4DOS is just a command interpreter, same as nDOS. They work on MS-DOS, FreeDOS ets.

http://en.wikipedia.org/wiki/4DOS

About uses of FreeDOS see please:

http://en.wikipedia.org/wiki/Freedos#Commercial_uses

104. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 05, 2013
• 4300 views

I think you are getting ahead of yourself here. Before that, do we have anyone who can maintain a version of Euphoria that runs under MS-DOS? Since I sent out my open call for dos developers - http://openeuphoria.org/forum/m/112542.wc - nearly three years ago, exactly one person has expressed interest - but that person was not a programmer.

BRyan - who hasn't explicitly expressed interest in becoming an official DOS developer for Euphoria yet - has come the closest to becoming that DOS developer. However, and by no means am I disparaging BRyan's skills as a coder, but he was unable to deal with relatively simple cases of bitrot in the codebase (e.g. DOSFAMILY). I think he now can maintain what he has, but I suspect that he is probably not the DOS developer that I was looking for.

The view from the FreeDOS community seems to be that it wasn't worth the effort to revive Euphoria for DOS: http://www.bttr-software.de/forum/mix_entry.php?id=9244

If there was just one person who was willing and able to bring Euphoria back for DOS, then I'd say we should let them do it. The creator of Star Trek created his TV shows not for his audience, but for himself, after all (as recounted in a conversation between Wil Wheaton and Eugene Roddenberry, Jr. in Trek Nation: http://en.wikipedia.org/wiki/Trek_Nation).

I believe that I'm not the only one who feels that way:

However, that person does not seem to exist. Remember that the initial catalyst for dropping DOS support was a bug that no one could fix: http://openeuphoria.org/forum/107540.wc#107540 http://sourceforge.net/mailarchive/message.php?msg_id=23280577

(If it requires a huge number of changes, then it might make more sense to revive the DOS port as a fork than to re-intergrate it back into the main tree, but that's a technical detail.)

106. Re: dos is a lost cause !

• Posted by jimcbrown (admin) Jul 05, 2013
• 4288 views

MSDOS is not an operating system: "DOS is more properly a set of relatively simple interrupt services." ( http://www.catb.org/jargon/html/M/MS-DOS.html ) You're practically running on the bare hardware.

This actually seems like a benefit for certain types of development (e.g. http://www.bttr-software.de/forum/board_entry.php?id=11973&da=DESC&page=0&order=last_answer&descasc=DESC&category=all ) but I don't think Euphoria is suitable for this sort of thing at all.

108. Re: dos is a lost cause !

• Posted by BRyan Jul 05, 2013
• 4273 views

You said: 
"Sorry, but it was just frustrating to hit the same wall over and over." 
"Of course, not all the issues were your fault - the DOS code had bitrotted by the time" "the snapshot was made and no longer built on its own." 
 
You also said: 
"However, and by no means am I disparaging BRyan's skills as a coder, but he was unable" "to deal with relatively simple cases of bitrot in the codebase (e.g. DOSFAMILY)." 
 
 
 
 
 
I was given information that the code in the archive was correct and working code. 
 
After trying to compile the code for hours. 
 
I kept discovering all kinds of errors and conflicts which could not be compared with 
4.0.5 or any older code that existed.  
 
Of course it was ok for you to run into the wall and to encounter bitrotted 
 
but I should have been able to solve those simple problems. 
 
In addition it is still possible to use Euphoria DOS programs via NTVDM in WinXP 
 
which gives you a little more access to the hardware. 
 
As user's know trying to emulate DOS code with dos rescue is not an easy solution. 
 

110. new DOS source

• Posted by BRyan Jul 05, 2013
• 4320 views

The corrected and updated DOS version of Euphoria should be made available. 
 
It should be placed on the download page. 
 
Then the users who are interested in it, can test their code on it. 
 
This will also show if there is any interest in using it. 

112. Re: new DOS source

• Posted by jimcbrown (admin) Jul 05, 2013
• 4231 views

I agree with this. However, technical difficulties prevent me from committing the fixes to the SVN repo at SF at this time.

I'm not sure that I'd agree with this - that could imply a higher level of support than what would actually be provided.

In any case, the same technical difficulties prevent me from modifying the Downloads/Files section at SF at this time.

Interest in using it is a secondary issue. The primary one remains - who will maintain/support this codebase? None of the current devs have the time/experience/inclination to do this.

BRyan, are you volunteering for this job?

114. Re: new DOS source

• Posted by jimcbrown (admin) Jul 06, 2013
• 4218 views

Are you saying we don't need a maintainer for projects that do have a lot of interest from the general public?

Well, by analogy, there is plenty of interest in cloning a dinosaur. But just because there is a lot of interest in cloning a dinosaur does not mean we'll get a cloned dinosaur.

Likewise, there may be plently of interest in having an Euphoria version for DOS, but if no one can maintain or fix bugs in that project, then it's still a dead project.

I always assumed that we did have major interest in a DOS version (major users bring BRyan, kinz, achury, eukat, but also probably a 'silent' majority), but we had to drop DOS support despite that since there was no longer any individual capable of maintaining it.

It's already available to the public, though not all in one place.

The repository should be updated (so it is all in one place and easy to download), but due to technical difficulties I can't do it atm. (It'd probably be easier to add an hg repo for it than to deal with SF, but I'm reluctant to personally invest the major effort that would be involved until/unless a DOS developer actually does join the team.)

Agreed. The source is out there, and the call for dos developers is still open. Three years and counting....

116. Re: new DOS source

• Posted by useless_ Jul 07, 2013
• 4080 views

I am of the opinion the dos version matters just as much. Assuming it has the same command words as olde msdos5, will it be actually msdos5, or will it also be a strict clone of msdos5, or a modern flat memory model 32bit multitasking dos and a filesystem above FAT32? The hardware we have now to run dos on is 20 years beyond what we had in the msdos6 days, i feel using an advanced dos on it is a Good Thing, but throwing that hardware out because dos won't use it is a Bad Thing.

Someone once said the dos underlaying win95 could be yanked out and used seprately, i'd vote for that, except for the copyrights. And limitation to FAT32.

useless

118. Re: new DOS source

• Posted by useless_ Jul 07, 2013
• 4048 views

"the dos version" = "that version of dos"
"Eu version 4, Eu version 3.11" . "MSdos version 5, MSdos version 7.1"

That said, i now give up already, it's not worth getting sucked into more word games.

useless

120. Re: new DOS source

• Posted by jimcbrown (admin) Jul 07, 2013
• 4130 views

I ask this since I had a hard time parsing andi49's sentence, so I'm not actually sure at all what is being said here.

I'm much more inclined to agree with this than with what I think andi49 said. However, ultimately I feel that if someone's joy is to do it, then we should let them. That's the FOSS way.

No one said "exclusively". Don't compare apples to oranges.

I don't need to assume this - we already know people on this forum who want to use Euphoria to develop new applications that are designed to explicitly run on DOS platforms. In addition, they also want to be able to maintain and extend existing applications that ran on DOS in earlier versions.

Um, BRyan (and his claimed userbase that he's trying to support), achury, eukat, ....

Based on the lack of answer to my open call for dos developers, I'd agree that there seems to be little interest in working on something like this. On the other hand, I'd argue that supporting DOS is worth more than supporting Windoze 9x - but we continue to do that since a few users still use it and supporting them is so cheap (so we are able to distinguish ourselves from other things that have fropped 9x support).

The full cost-benefit analysis matters here - and as Jeremy pointed out, DOS support was extremely expensive. Therefore, it's reasonable to ask for a higher level of interest for DOS. Ultimately, though, I feel that if someone's joy in life is to do this, why not let them?

Please identity them. I, a current member of the developer team, certainly have no idea who they could be.

That bug (getting call_back() to work on DOS, something that had never been the case in all of the history of Euphoria) is arguably still there. Who on this forum or de list knows enough about C and DOS extenders to get the machine code for a callback through the Causeway DOS extender so it can be called without crashing the entire application? Even Rob Craig probably didn't know how to do this (which was most likely the reason that call_back() was not supported/implemented for DOS during the time when he maintained it).

(Of course, even if someone could do it, it doesn't mean that they should be forced to do it. It's not like any of the current devs are getting paid to maintain any edition of Euphoria, after all. Everyone is doing it out of fun or love or whatever...)

Sure, if we have to raise money and pay a professional software house to do it or something. However, I don't see the harm in testing the waters to see if anyone out there is simply interested in becoming a maintainer for it - perhaps because it's fun for them, or because they think it's neat to run a modern language on a retro environment, etc. Since I know we definitely have some users who would be interested in having someone else maintain it,

I think this is a win-win situation - those who are interested in a DOS edition (even if it it turns out to be a super tiny minority) get what they want, the maintainer gets what they want (fun, since they're doing it just for fun, or whatever), and since the rest of us don't need to get involved, it doesn't cost us anything.

Besides, there is actually some work involved in determining if there is an interest in something or not, to the point that companies spend tens of thousands of on it (e.g. http://www.fastcompany.com/1713068/insta-focus-group-gutchecks-diy-market-research ).

I don't think we need to go that far, but since you put so much important on actually determining the interest level in a DOS edition, I have to ask this.

Derek, are you willing to run a poll - or gather the data using other methods - to actually and accurately gauge the interest level in a DOS edition? If you aren't, then perhaps you would be unwise to simply assume that there is "next to zero interest" without any evidence to back it up.

122. Re: new DOS source

• Posted by jimcbrown (admin) Jul 07, 2013
• 4060 views

Well, I didn't necessarily mean a poll here. Though it would be a logical place to start, there are probably other places that should be polled as well (e.g. simtel forums, freedos mailing lists, etc).

Agreed.

Might being the opperative word here. I suspect that it'd not be the case for most users, who would use the Arduino for very low level operations (like emulating an SID chip or acting as a microcontroller) that a full fledged DOS computer, with its clunky BIOS requirement and need to have some kind of random access hardware (flopy or hard disk) would be ill-suited for. Again, though, there's no accounting for individual taste.

Sadly, with things like TPM and VT, that "unfettered" hardware access is growing more and more distant at the hardware level itself.

I see some differences that may make a huge difference to some. E.g. USB legacy support causes a timer to run that can not be masked out (not even with STI/CLI) that takes up to 400-500us. Older systems that don't support USB at all don't have this problem and can run code that must be run at 25-30 us resolution.

This sort of thing may not be a problem for you personally, but it's probably a problem for someone out there.

Also, there is no 64bit version of DOS, so it's still not possible to use more than 4GB of ram in a single DOS application.

DOSEmu - which runs in a shell (e.g. bash) on a box that boots nix, has had support for direct hardware access for over a decade. http://www.dosemu.org/docs/README/1.2/config.html

Edit: And you can run eui (or other nix commands) from inside a DOSEmu session via DOSEmu's unix.com utility. http://www.dosemu.org/stable/announce

124. Re: new DOS source

• Posted by jimcbrown (admin) Jul 07, 2013
• 4133 views

The BIOS is required to boot DOS. For the Arduino, a bootloader is optional and it can be removed in its entirety.

Also, the Arduino bootloader is only 2K (and can be shrunk to 0.5K http://forum.arduino.cc/index.php/topic,38002.0.html ) while a typical modern BIOS can be as big as 1024K (e.g. http://www.cyberciti.biz/faq/check-bios-version-linux/ )

Agreed. But you can't get rid of it completely if you don't want it/need it - at best you can just bypass it after DOS has finished booting. That level of total control is denied.

Agreed.

I know that there are actually attempts to do build full fledged computer systems out of the Arduino (e.g. http://electronics.stackexchange.com/questions/19793/making-a-functional-computer-out-of-an-arduino-uno ). It's not so much about the "full fledged" bit, but rather the historical cruft that a computer capable of running DOS on it would bring with it that makes it unsuitable as a replacement for an arduino.

Of course, you could take the requirement for that stuff out of DOS (e.g. using the FreeDOS or DR-DOS/OpenDOS code as a base, remove the need to boot from a BIOS), but anyone with the skills to do that could probably get DOS running on the Arduino itself. I take that to mean that virtually all the niches that a computer running DOS could fulfill, could also be done by either a modern server system running Linux/GNU or an Ardiuno.

Ignoring alphas and prealphas, and assuming one means a native DOS edition port, then yes. However, the idea here was to "cheat" by running the Linux/GNU edition of Euphoria on DOS through this DOSEmu setup.

You should be able to get DOSEmu installed from a binary distribution (no compiling!). In general though this can be true (I once spent three days trying to get wxUniversal to compile on a Linux/GNU system, though this was over a decade ago).

Agreed - there is a lot of complicated setup involved in getting DOSEmu to be able to grant direct access to the hardware. You'd probably be on your own if you wanted to give that a try.

Yes, precisely.

I haven't personally tested this, but you should be able to use more than 4GB of ram in a single Euphoria application that runs on 64bit XP using the 64bit version of Euphoria.

How is this modern? Ramdisks have been around since the time of CP/M. Linux/GNU has had support for using ramdisks as the root since virtually the beginning.

Edit: My mistake. Booting DOS from C: as a ramdisk does seem to be relatively modern: http://www.styma.org/bootcdrom/bootcdrom.shtml

I assumed that, since Linux/GNU has had support for using ramdisks a root for several decades now, that something as flexible and extendable as DOS should have had it for just as long as well. My mistake.

126. Re: new DOS source

• Posted by jimcbrown (admin) Jul 07, 2013
• 4060 views

Because it can still get in the way even if I don't want to use it. E.g. that 400-500us timing loop for USB legacy support.

Also, even if I'm not using it, it's still taking up space in memory since it's mapped into the address space. What if I want to use that space for something else?

Agreed, I admit that it isn't true - with modern technology you can downgrade to booting DOS from sequential access hardware instead! http://www.geekinterview.com/question_details/34494

Edit: The original point that I intended to make stands. An arduino remains superior as it doesn't need random access hardware or a CD drive to load its code, unlike DOS.

128. Re: new DOS source

• Posted by jimcbrown (admin) Jul 07, 2013
• 4056 views

Agreed. It requires an SD card. The Arduino does not. Don't change the topic.

Which brings along all the cruft involved in booting from and using random access hardware again (as that pata ssd emulates the interface to a standard hdd, even if it isn't random access itself).

Pata ssds are about the size of a standard hard disk. An SD card is a lot smaller. Both the Pi and the Arduino take up less room (in terms of physical space used) than a conventional DOS system.

Agreed.

Of which you can only use 4.

Anyways, the point is that as one of the Real Programmers(tm) who knows what they are doing, I should have the right and the option to get rid of that 1MB if I don't want or need it.

If someone were to ask me why I felt that I need to have this right, I'd counter with "Well, why should the programmer want direct access to the hardware when it can be emulated perfectly by a full fledged modern OS and dosbox?" It all boils down to the same thing.

I was not aware that it was possible to page out or overwrite the BIOS in this manner. My research has consistently suggested the opposite is true.

Even if this is true for legacy BIOSes, would this still hold true for its successor, EFI? Perhaps this is a moot point, considering how difficult it is to get DOS to run on an EFI-only system...

130. Re: Open Call for DOS Developers

• Posted by jimcbrown (admin) Jul 07, 2013
• 4030 views

I disagree. I think it does.

I wouldn't trust that as an accurate indicator, as one user might just be hitting reload repeatedly.

I think it's reasonable here to be able to ask for help from the larger dev community on details like the build process. Certainly, the dev team is at fault for 1) releasing the DOS branch without properly understanding the level of bitrot that had already crept in and 2) for mungling the release itself.

That is out of date and should be removed. Those instructions have been superceded by the wiki at http://openeuphoria.org/wiki/view/Compiling40.wc but even that's out of date with regards to the yet-unreleased 4.1 (which uses GCC and the standard configure - make process).

The build instructions should be updated once 4.1.0 is released, but this is a different matter than that of supporting the DOS branch.

As the person who wrote the code to do this (because before I wrote it, there was no way to do it at all - and you still can't do it in the 3.1.1 or 4.0.x codebase afaik), I feel that I am the one reponsible for the lack of documentation regarding this.

I can not think up of any reason that would justify this lack of documentation. I believe that the author of this feature should take full responsibility and provide adaquate documentation for it.

See http://scm.openeuphoria.org/hg/euphoria/file/bdcbd57525de/source/backend.e#l284 for an example of how to pass a call to the backend.

See http://scm.openeuphoria.org/hg/euphoria/file/bdcbd57525de/source/be_machine.c#l2879 for an example of how to retrieve a call from the frontend in the backend.

See http://scm.openeuphoria.org/hg/euphoria/file/bdcbd57525de/source/be_coverage.c and http://scm.openeuphoria.org/hg/euphoria/file/bdcbd57525de/source/be_syncolor.c#l65 for examples of how to actually make the call to the frontend code from the backend.

See http://scm.openeuphoria.org/hg/euphoria/file/bdcbd57525de/source/be_machine.c#l2624 for the implementation of the method itself that makes this possible.

The reason you couldn't find it was probably because you were looking in the wrong places. E.g. the 4.0 codebase doesn't implement or support this: http://scm.openeuphoria.org/hg/euphoria/file/74222c439548/source/backend.e#l338

This hasn't changed from the 3.1.1 days. If you can add a new feature to the C backend in 3.1.1, then you should have an easy time of doing it with 4.0.5 or even 4.1.0 as well.

Of course, I think having explicit documentation on how to add a feature is a very good idea.

Well, you have a working codebase now. It should be easy enough for someone as experienced as you to prove me and my criticism wrong. ;)

132. Re: new DOS source

• Posted by andi49 Jul 07, 2013
• 3993 views

Hi,
Sorry for the late reply. It took some time read all the posts.

Excuse my bad english please.
What i meant is: You only need a maintainer for the project 'if' there is any interest.
If there is no interest, then you do not need a maintainer.

Well, by analogy, there is plenty of interest in using Windows or Linux. But very few people have the ability to maintain the sourcecode of these projects

That's all I'am askin for. Just put a working copy of the project in 'one' place and give everyone interested a chance to use it.

Again, just put the source togehter, in one place, so the not so experienced developers have a starting point.

To make makes things more clear:
I'am not interested in a DOS-Port (and i mean DOS not Windows Console).
I can't believe anyone uses pure Dos as a Operating System, except for some older production machines somewhere in the industry (for controling purposes etc.)

But i think if there is a download for a 'working' project, then the discussion about a Dos-Port will end...
Andreas

134. Re: new DOS source

• Posted by DerekParnell (admin) Jul 07, 2013
• 3982 views

I have the ability to maintain a DOS edition of Euphoria, but I don't want to do that. I have no interest in supporting something that I think is a pointless exercise. I used to code DOS applications using assembler and BIOS calls (official and unofficial), and I've written plenty of TSRs and device drivers. I think I still have the full source code for the IBM-DOS bios.

But anyhow, I'm no longer sure about what it is you are talking of. Are we talking about an edition of Euphoria that runs and can be used to develop applications that run on MS-DOS? Or are you talking about developing a version of MS-DOS in Euphoria - an Euphoria-coded operating system?

I'm confused because MS-DOS is copyrighted, as is OS/2 and AmigaDOS etc etc etc ... but what has that got to do with developing an Edition of Euphoria to run on those platforms. One doesn't need to "buy out the various legal rights" in order to run those operating systems nor to develop applications that run on them - and Euphoria is just an application from that point of view.

So again I ask, is there any real need for an edition of Euphoria (v4+) that runs on the (or any) DOS operating system? Anyone?

Now if someone wanted to port Euphoria to AmigaDOS I might be interested because I'm still in love with that opsys, even though almost no-one uses it anymore.

136. Re: new DOS source

• Posted by jimcbrown (admin) Jul 08, 2013
• 3971 views

Which is the central point of this "Open Call for DOS Developers" - there might be someone out there for whom porting Euphoria to FreeDOS (et al) might be a labour of love. The original genesis of FreeDOS itself falls under this category.

The former.

I was continuing the examples from andi49, which were all operating systems. It's not necessary to buy out the legal rights to develop applications that run on them. It is necessary to buy out the legal rights to be able to continue to develop the operating systems themselves.

I could just as easily used Corel WordPerfect, WordStar, or Lotus 1-2-3 as examples.

Just so we're clear, you are doing a complete 180 from what you said nearly 4 years ago. http://sourceforge.net/mailarchive/message.php?msg_id=23280577

If you say this, I don't believe it's possible for me to prove or disprove a claim like this, so I'll have to take your word for it. A justification for the 180 would make this easier to swallow, naturally....

I would also tenatively advise that finding and fixing issues in a 32bit DOS program (or even the DOS Extender itself) is vastly different than writing 16bit DOS TSRs / device drivers in assembly language. Thus you may very well have a wide experience with developing DOS code in general, and perhaps even managed to keep it fresh and active (as opposed to abandoning all DOS work years or decades ago and to the point that it'd take some time to get back into it), but it still may not be enough of the right kind.

I agree that those who believe that they have evidence that many users want Euphoria on DOS, or simply want it for themselves, should speak up now and show their evidence or state their reasons.

Are you stating, Derek, that if you did in fact (hypothetically) see enough of a real need, that you would indeed begin maintaining the DOS edition of Euphoria again, despite your personal lack of interest in such a task otherwise? How would you define a "real need" and what would it take to get you to do this (hypothetically of course) ?

138. Re: new DOS source

• Posted by DerekParnell (admin) Jul 08, 2013
• 3959 views

Huh? You lost me (again). I don't get the connections you are hinting at.

If a 'real need' was demonstrated, then the probability of me assisting in supporting the needed tool would be greatly increased. Of course, other factors would have to be considered in conjunction.

'real need' =(approx) 'more than a few independant developers demanding Euphoria support for a specific platform'

"what would it take to get you to do this" Hmmmm ... payment for services rendered would go a long way

140. Re: new DOS source

• Posted by jimcbrown (admin) Jul 08, 2013
• 4117 views

Now you've set a higher standard than for any other edition or version of Euphoria since Euphoria became open source. Just saying.

On the other hand, it'd certainly be money well earned and well deserved.

I'd take that as a no in that case, as demonstration of a 'real need' is not enough - other factors (like, amount of spare time and payment for services rendered) have to be considered in conjunction.

I guess this is a moot point (since having a 'real need' is not enough by itself), but that definition is too vague to be useful. What's more than a few? How many more?

Or perhaps this is one of those cases where one says, "I can't give you a dictionary definition, but if I saw one, I'd recognize it on sight." ?

You spent a whole day ('all day') on it and still couldn't figure out why the DOS edition kept crashing... but claim to be able to maintain it.

142. Re: new DOS source

• Posted by DerekParnell (admin) Jul 09, 2013
• 3869 views

How long is a piece of string? Exactly twice the distance from one end to the center.

Whatever.

Hyperbole.

Not a DOS issue.

Meh.

144. Re: new DOS source

• Posted by useless_ Jul 09, 2013
• 3809 views

Did you count the number of people who could and would, but won't because they have better things to do than get sucked into this sort of "discussion"?

useless

146. Re: new DOS source

• Posted by useless_ Jul 09, 2013
• 3823 views

Yes of course, but i was using a different definition of "not willing".

useless

148. Re: new DOS source

• Posted by useless_ Jul 09, 2013
• 3805 views

Do you mean "a different definition of already" or "a different definition of "already""?

useless

150. Re: new DOS source

• Posted by useless_ Jul 09, 2013
• 3846 views

Ah, the difference tween "different." and ""different".". So many people don't see the distinction.

useless

152. Re: new DOS source

• Posted by jimcbrown (admin) Jul 09, 2013
• 3796 views

I've managed to resolve those difficulties and uploaded the fixes.

However, I should point out that sourceforge.net has migrated the repositories that they host. http://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/

Here is the new SVN URL:

https://svn.code.sf.net/p/rapideuphoria/code/dos/trunk/

154. Re: new DOS source

• Posted by jimcbrown (admin) Jul 10, 2013
• 3733 views

Ignore the readme - it's out of date. Build using OpenWatcom by running configure.bat and wmake.

A build using DJGPP might also work, but I haven't tested this. If it still works, you should be able to do it by running ./configure inside a bash shell, and then running make.

156. Re: new DOS source

• Posted by useless_ Jul 10, 2013
• 3688 views

The zip isn't publicly linked on my site, i had removed all the Euphoria references and pages when i became useless here. The url for the binaries is http://DesignerThinking.com/eu40-2434.zip

useless

158. Re: new DOS source

• Posted by bugmagnet Jul 10, 2013
• 3694 views

Getting closer

Open Watcom Make Version 1.9 
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved. 
Source code is available under the Sybase Open Watcom Public License. 
See http://www.openwatcom.org/ for details. 
------- ALL ----------- 
	wmake -h winall DEBUG= MANAGED_MEM=1 CONFIG=config.wat 
------- WINALL ----------- 
wmake -h interpreter DEBUG= MANAGED_MEM=1 CONFIG=config.wat 
wmake -h C:\eu4dos\trunk\source\intobj\main-.c EX=c:\Euphoria\bin\eui.exe EU_TARGET=int. OBJDIR=intobj DEBUG= MANAGED_MEM=1 CONFIG=config.wat DEBUG= MANAGED_MEM=1 
del /Q C:\eu4dos\trunk\source\intobj\back\*.* 
del /Q C:\eu4dos\trunk\source\intobj\*.* 
cd  C:\eu4dos\trunk\source\intobj 
c:\Euphoria\bin\eui.exe -i C:\eu4dos\trunk\include -d DOSFAMILY C:\eu4dos\trunk\source\ec.ex   -d DOSFAMILY -nobuild -wat -plat WIN -d DOSFAMILY -D EU_MANAGED_MEM  -i C:\eu4dos\trunk\include C:\eu4dos\trunk\source\int.ex 
option '-EUDIR': Unrecognised 
 
euc.exe [options] file.ex... 
 common options: 
   [-batch]       Turn on batch processing (do not "Press Enter" on error) 
   [-c filename]  Specify a configuration file 
   [-copyright]   Display all copyright notices 
   [-d word]      Define a preprocessor word 
   [-i dir]       Add a directory to be searched for include files 
   [-l local]     Defines a localization qualifier 
   [-ldb localdb] Defines the base name for localization databases 
   [-p file_ext:command]Setup a pre-processor 
   [-pf]          Force pre-processing regardless of cache state 
   [-strict]      Enable all warnings 
   [-test]        Test syntax only, do not execute. Implies batch mode. 
   [-version]     Display the version number 
   [-w name]      Defines warning level 
   [-wf filename] Write all warnings to the given file instead of STDOUT 
   [-x name]      Defines warning level by exclusion 
 
 translator options: 
   [-silent]          Do not display status messages 
   [-wat]             Set the compiler to Watcom 
   [-djg]             Set the compiler to DJGPP 
   [-gcc]             Set the compiler to GCC 
   [-com dir]         Set the compiler directory 
   [-con]             Create a console application 
   [-dll]             Create a shared library 
   [-so]              Create a shared library 
   [-plat platform]   Set the platform for the translated code 
   [-lib filename]    Use a non-standard library 
   [-fastfp]          Enable hardware FPU (DOS option only) 
   [-stack size]      Set the stack size (Watcom) 
   [-debug]           Enable debug mode for generated code 
   [-maxsize size]    Set the number of C statements per generated file before splitting. 
   [-keep]            Keep the generated files 
   [-makefile]        Generate a project Makefile 
   [-makefile-full]   Generate a full project Makefile 
   [-cmakefile]       Generate a project CMake file 
   [-emake]           Generate a emake/emake.bat file to build project 
   [-nobuild]         Do not build the project nor write a build file 
   [-builddir dir]    Generate/compile all files in 'builddir' 
   [-o filename]      Set the output filename 
Error(E42): Last command making (C:\eu4dos\trunk\source\intobj\main-.c) returned a bad status 
Error(E02): Make execution terminated 
Error(E42): Last command making (interpreter) returned a bad status 
Error(E02): Make execution terminated 
Error(E42): Last command making (winall) returned a bad status 
Error(E02): Make execution terminated 
Error(E42): Last command making (all) returned a bad status 
Error(E02): Make execution terminated 

160. Re: new DOS source

• Posted by bugmagnet Jul 10, 2013
• 3543 views

c:\Euphoria\bin\eui.exe -i C:\eu4dos\trunk\include -d DOSFAMILY C:\eu4dos\trunk\source\ec.ex   -d DOSFAMILY -nobuild -wat -plat WIN -d DOSFAMILY -D EU_MANAGED_MEM  -i C:\eu4dos\trunk\include C:\eu4dos\trunk\source\int.ex 
option '-EUDIR': Unrecognised 

Please have a look at DOS compile in pastey. Huge list of missing symbols.

Bugmagnet

162. Re: new DOS source

• Posted by DerekParnell (admin) Jul 11, 2013
• 3500 views

What is your LIB= environment symbol set to. It should be set to the Watcom lib386 directory. For example ...

LIB=C:\WATCOM\lib386 

164. Re: new DOS source

• Posted by bugmagnet Jul 11, 2013
• 3473 views

LIB=C:\WATCOM\lib386 

Okay, using

lib=C:\Euphoria\watcom\LIB386;C:\Euphoria\watcom\LIB386\NT 

It's still not building completely.

Bugmagnet

166. Re: new DOS source

• Posted by bugmagnet Jul 11, 2013
• 3479 views

Twould seem to be the case that I need more than the Watcom that comes with OpenEuphoria 4.0.x. Am in the process of downloading the OpenWatcom C compiler for DOS. Is that going to do the trick?

Bugmagnet