1. Can't compile DOS program with long file name

Hello Rob,

I have the following test program:
puts(1, "Hello!\n\nPress Enter ...")
if getc(0) then end if

and the name of the program file is "small_test_program.ex".

The program works when interpreted with ex.exe 2.5, but the problem
is that I can't make a DOS .exe program out of it.
Translating with ec.exe 2.5 seems to work fine, but when I run
"emake.bat" I get compiler errors, and no .exe file is produced.
This happens when I try to compile with DJGPP 2.03, and also with
Open Watcom 1.3. I'm using Windows 98.
When I rename the program file to a short name such as "test.ex"
translating/compiling works fine, so I think the long file name causes
the problem. The problem also arises when a program includes a file
with a long name.

Is it possible for the Euphoria 3.0 DOS translator to solve this
problem? I would appreciate that very much!

Regards,
   Juergen

new topic     » topic index » view message » categorize

2. Re: Can't compile DOS program with long file name

Juergen Luethje wrote:
> I have the following test program:
> }}}
<eucode>
> puts(1, "Hello!\n\nPress Enter ...")
> if getc(0) then end if
> </eucode>
{{{

> and the name of the program file is "small_test_program.ex".
> 
> The program works when interpreted with ex.exe 2.5, but the problem
> is that I can't make a DOS .exe program out of it.
> Translating with ec.exe 2.5 seems to work fine, but when I run
> "emake.bat" I get compiler errors, and no .exe file is produced.
> This happens when I try to compile with DJGPP 2.03, and also with
> Open Watcom 1.3. I'm using Windows 98.
> When I rename the program file to a short name such as "test.ex"
> translating/compiling works fine, so I think the long file name causes
> the problem. The problem also arises when a program includes a file
> with a long name.
> 
> Is it possible for the Euphoria 3.0 DOS translator to solve this
> problem? I would appreciate that very much!

The ec.exe translator is a Euphoria program, translated (by itself!) 
and compiled with Watcom for DOS. As such, it can open existing files 
that have long names, but it can't create new files with long names.
This problem has been noted before.

What I could do is either: 
   1. start using your DOS long file name routines
or 
   2. have one translator for both DOS and Windows, 
      i.e. extend ecw.exe to handle DOS translations as well

I'd prefer #2, since it would eliminate an executable that I have
to build, and it's probably quite easy to do. I'll look into it.

Thanks,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

3. Re: Can't compile DOS program with long file name

Robert Craig wrote:

> Juergen Luethje wrote:
>
>> I have the following test program:
>> }}}
<eucode>
>> puts(1, "Hello!\n\nPress Enter ...")
>> if getc(0) then end if
>> </eucode>
{{{

>> and the name of the program file is "small_test_program.ex".
>>
>> The program works when interpreted with ex.exe 2.5, but the problem
>> is that I can't make a DOS .exe program out of it.
>> Translating with ec.exe 2.5 seems to work fine, but when I run
>> "emake.bat" I get compiler errors, and no .exe file is produced.
>> This happens when I try to compile with DJGPP 2.03, and also with
>> Open Watcom 1.3. I'm using Windows 98.
>> When I rename the program file to a short name such as "test.ex"
>> translating/compiling works fine, so I think the long file name causes
>> the problem. The problem also arises when a program includes a file
>> with a long name.
>>
>> Is it possible for the Euphoria 3.0 DOS translator to solve this
>> problem? I would appreciate that very much!
> 
> The ec.exe translator is a Euphoria program, translated (by itself!)

This is really cool. smile

> and compiled with Watcom for DOS. As such, it can open existing files
> that have long names, but it can't create new files with long names.
> This problem has been noted before.

Yes, it has. However, I personally was not aware of the fact that this
implies the impossibility to translate program files with long names.

> What I could do is either:
>    1. start using your DOS long file name routines
> or
>    2. have one translator for both DOS and Windows,
>       i.e. extend ecw.exe to handle DOS translations as well
 
Or would it help to compile ec.ex wirh DJGPP instead of Watcom?

> I'd prefer #2, since it would eliminate an executable that I have
> to build, and it's probably quite easy to do.

If that means that you'll save some time, then it's probably a good idea
anyway. smile

> I'll look into it.

Thanks!

> Thanks,
>    Rob Craig
>    Rapid Deployment Software
>    <http://www.RapidEuphoria.com>

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

4. Re: Can't compile DOS program with long file name

Robert Craig wrote:

> What I could do is either: 
>    1. start using your DOS long file name routines
> or 
>    2. have one translator for both DOS and Windows, 
>       i.e. extend ecw.exe to handle DOS translations as well
> 
> I'd prefer #2, since it would eliminate an executable that I have
> to build, and it's probably quite easy to do. I'll look into it.
> 

Rob wait just a second here.

"ecw.exe" is a Windows NT executable right? Windows executables do not run in
pure DOS environments. I use DOS Euphoria and the DOS translator in pure DOS 6.22
on my Pentium 133 MHz machine. Doing this would mean I can no longer use the
translator in pure DOS.

Extending "ec.exe" might work since DOS exectuables run with DOS emulation on
Windows XP and older. However I dont know if Windows Vista will support DOS
programs. I know for a fact that Microsoft will be removing the WOW 16 bit
application subsystem in Windows Vista. What that means is you wont be able to
run 16 bit programs in Vista. I believe ntvdm.exe is another piece of this and if
they remove it we will not be able to run the DOS Euphoria interpreter, binder,
backend, or translator as well. I can delete ntvdm.exe and Windows will recreate
a copy automatically however I can make the DOS programs fail to run for a few
moments. If its completely removed in Vista it wont ever work.

So what I'm saying is *please* do not do this. Just make the two seperate
translator executables like you always have. I think this is to big of a risk to
chance.


Regards,
Vincent

new topic     » goto parent     » topic index » view message » categorize

5. Re: Can't compile DOS program with long file name

Vincent wrote:

> 
> Robert Craig wrote:
> 
> > What I could do is either: 
> >    1. start using your DOS long file name routines
> > or 
> >    2. have one translator for both DOS and Windows, 
> >       i.e. extend ecw.exe to handle DOS translations as well
> > 
> > I'd prefer #2, since it would eliminate an executable that I have
> > to build, and it's probably quite easy to do. I'll look into it.
> > 
> 
> Rob wait just a second here.
> 
> "ecw.exe" is a Windows NT executable right? Windows executables do not run in
> pure DOS environments. I use DOS Euphoria and the DOS translator in pure DOS
> 6.22 on my Pentium 133 MHz machine. Doing this would mean I can no longer use
> the translator in pure DOS.
> 
> Extending "ec.exe" might work since DOS exectuables run with DOS emulation on
> Windows XP and older. However I dont know if Windows Vista will support DOS
> programs. I know for a fact that Microsoft will be removing the WOW 16 bit
> application
> subsystem in Windows Vista. What that means is you wont be able to run 16 bit
> programs in Vista. I believe ntvdm.exe is another piece of this and if they
> remove it we will not be able to run the DOS Euphoria interpreter, binder,
> backend,
> or translator as well. I can delete ntvdm.exe and Windows will recreate a copy
> automatically however I can make the DOS programs fail to run for a few
> moments.
> If its completely removed in Vista it wont ever work.
> 
> So what I'm saying is *please* do not do this. Just make the two seperate
> translator
> executables like you always have. I think this is to big of a risk to chance.
> 
> 
> Regards,
> Vincent

Hi Vincent,

There is an interesting link about modern DOS':

http://www.undercoverdesign.com/dosghost/dos/dosw31.asp#top

EU works on all, I have tried it on MS, DR, Free, PTS 2000, PTS32.
---

Hi Rob,

The #2 may lead to restrictions about functionality of EU at all,
wait please not just a second here, but 2 seconds at least.
The DOS32 EU is the most complete Ephoria - the classic EU, so to say.
It deserves to be supported forever, I think.
---

Hi Juergen,

I think, renameing of an input file for ec.exe is an excellent
workaround for this issue, maybe, just document this issue better?
What to do if these old good DOS file names are just 8.3?
---

Good Luck to all!

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

6. Re: Can't compile DOS program with long file name

Igor Kachan wrote:

<snip>

> Hi Rob,
> 
> The #2 may lead to restrictions about functionality of EU at all,
> wait please not just a second here, but 2 seconds at least.
> The DOS32 EU is the most complete Ephoria - the classic EU, so to say.
> It deserves to be supported forever, I think.
> ---

After thinking more about it, I agree with you and Vincent that people
who want to compile a Euphoria DOS program should not be forced to use
Windows in order to do so. So the DOS compiler should be a pure DOS
program.

> Hi Juergen,
> 
> I think, renameing of an input file for ec.exe is an excellent
> workaround for this issue, maybe, just document this issue better?

Yes, I was surprised when I realized the issue, because I hadn't read
about it in the Euphoria documentation. (Maybe it is not documented?)

Renaming of an input file _sometimes_ can be a workaround. Sometimes
this won't help much, because the problem does not only affect the
program file which we want to compile, but _also included files_, as I
mentioned previously.
And I certainly _never_ would consider it "excellent", when I'm forced
to rename files because of this unnecessary issue.

Since I always try to write code in include files as generic and
cross-platform as possible, your suggestion means that I would have to
rename all my .e library files, so that they only use old DOS 8.3 names.

Just last week at work, I had to search for some old files (about 10
years old) on CD, which all had 8.3 DOS names. It was a pain! I am very
happy that we now can use more characters in order to give the files
more meaningful names. I don't understand why I deliberately should want
to do without it.

And it should be easy for Rob to fix it. Just compiling ec.ex with DJGPP
instead of Watcom probably should do the trick, see:
<http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=A&toMonth=8&toYear=A&postedBy=Juergen+Luethje&keywords=%222005+Aug+17+6%3A17%22>

If that would not work, a reliable DOS LFN library from the archieves
can be used.

> What to do if these old good DOS file names are just 8.3?

Sorry, I don't understand what you mean. Can you say it in other words,
please?

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

7. Re: Can't compile DOS program with long file name

Juergen Luethje wrote:
> 
> Igor Kachan wrote:
> 
> <snip>
> 
> > Hi Rob,
> > 
> > The #2 may lead to restrictions about functionality of EU at all,
> > wait please not just a second here, but 2 seconds at least.
> > The DOS32 EU is the most complete Ephoria - the classic EU, so to say.
> > It deserves to be supported forever, I think.
> > ---
> 
> After thinking more about it, I agree with you and Vincent that people
> who want to compile a Euphoria DOS program should not be forced to use
> Windows in order to do so. So the DOS compiler should be a pure DOS
> program.
> 
> > Hi Juergen,
> > 
> > I think, renameing of an input file for ec.exe is an excellent
> > workaround for this issue, maybe, just document this issue better?
> 
> Yes, I was surprised when I realized the issue, because I hadn't read
> about it in the Euphoria documentation. (Maybe it is not documented?)
> 
> Renaming of an input file _sometimes_ can be a workaround. Sometimes
> this won't help much, because the problem does not only affect the
> program file which we want to compile, but _also included files_, as I
> mentioned previously.
> And I certainly _never_ would consider it "excellent", when I'm forced
> to rename files because of this unnecessary issue.

Ok, it is not *too* excellent, it is just *almost* excellent.
It is just not that bad, I think now.

I know that German language does allow very and very long
combined words, it is just a champion language about long
words, but me myself can not say something like to
'ethyloxyethylparaphenilendiaminsulphate' without 5 breakes
in the middle of this not too long word.   smile 

> Since I always try to write code in include files as generic and
> cross-platform as possible, your suggestion means that I would have to
> rename all my .e library files, so that they only use old DOS 8.3 names.

Yes, if you want these libs to work on pure DOS, you have to
name them as 8.3. The Watcom compiler cares about pure DOS.
This Open Watcom supports 16 bit DOS too.

> Just last week at work, I had to search for some old files (about 10
> years old) on CD, which all had 8.3 DOS names. It was a pain! I am very
> happy that we now can use more characters in order to give the files
> more meaningful names. I don't understand why I deliberately should want
> to do without it.

What to do, it is just that old good time of PC, PC XT, PC AT etc. 

> And it should be easy for Rob to fix it. Just compiling ec.ex with DJGPP
> instead of Watcom probably should do the trick, see:

> <<a href="http://www.listfilter.com/cgi-bin/ ..  see next line
esearch.exu?fromMonth=8&fromYear=A&toMonth=8&toYear=A&postedBy= .. see next line
Juergen+Luethje&keywords=%222005+Aug+17+6%3A17%22"> .. see next line
http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth= .. see next line
8&fromYear=A&toMonth=8&toYear=A&postedBy= .. see next line
Juergen+Luethje&keywords=%222005+Aug+17+6%3A17%22</a>>  .. 

Ok, it is the end of your single word, Juergen ...  smile
I see now what you do like to see ...    smile

> If that would not work, a reliable DOS LFN library from the archieves
> can be used.
> 
> > What to do if these old good DOS file names are just 8.3?
> 
> Sorry, I don't understand what you mean. Can you say it in other words,
> please?

These EU DOS32 programs must to work on pure DOS.
Pure DOS names are 8.3.
Pure DOS doesn't understand long names anyway, so if you want
your program or lib to work on any pure DOS, you must rename long
names as 8.3. Nothing to do anymore.
What to do? Rename files or forget about pure old good DOS!

> 
> Regards,
>    Juergen

Good Luck!    smile

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

8. Re: Can't compile DOS program with long file name

Igor Kachan wrote:

> Juergen Luethje wrote:
>>
>> Igor Kachan wrote:
>>
>> <snip>
>>
>>> Hi Rob,
>>>
>>> The #2 may lead to restrictions about functionality of EU at all,
>>> wait please not just a second here, but 2 seconds at least.
>>> The DOS32 EU is the most complete Ephoria - the classic EU, so to say.
>>> It deserves to be supported forever, I think.
>>> ---
>>
>> After thinking more about it, I agree with you and Vincent that people
>> who want to compile a Euphoria DOS program should not be forced to use
>> Windows in order to do so. So the DOS compiler should be a pure DOS
>> program.
>>
>>> Hi Juergen,
>>>
>>> I think, renameing of an input file for ec.exe is an excellent
>>> workaround for this issue, maybe, just document this issue better?
>>
>> Yes, I was surprised when I realized the issue, because I hadn't read
>> about it in the Euphoria documentation. (Maybe it is not documented?)
>>
>> Renaming of an input file _sometimes_ can be a workaround. Sometimes
>> this won't help much, because the problem does not only affect the
>> program file which we want to compile, but _also included files_, as I
>> mentioned previously.
>> And I certainly _never_ would consider it "excellent", when I'm forced
>> to rename files because of this unnecessary issue.
> 
> Ok, it is not *too* excellent, it is just *almost* excellent.
> It is just not that bad, I think now.

I'm glad that it is fine for you. However, that does not change the fact
that it is everything else but excellent for me (as I wrote previously).

> I know that German language does allow very and very long
> combined words, it is just a champion language about long
> words, but me myself can not say something like to
> 'ethyloxyethylparaphenilendiaminsulphate' without 5 breakes
> in the middle of this not too long word.   smile

It does not matter whether or not I (or other Germans) can say so or not.
I'm 48 years old, an not too silly. So rest assure that I know myself
very well how to name my files properly.

>> Since I always try to write code in include files as generic and
>> cross-platform as possible, your suggestion means that I would have to
>> rename all my .e library files, so that they only use old DOS 8.3 names.
> 
> Yes, if you want these libs to work on pure DOS, you have to
> name them as 8.3.

Yes. But not if I use them in a DOS window on Windows. And it is _my_
decision what I want to do, not yours or anyone else's.

> The Watcom compiler cares about pure DOS.
> This Open Watcom supports 16 bit DOS too.
> 
>> Just last week at work, I had to search for some old files (about 10
>> years old) on CD, which all had 8.3 DOS names. It was a pain! I am very
>> happy that we now can use more characters in order to give the files
>> more meaningful names. I don't understand why I deliberately should want
>> to do without it.
> 
> What to do, it is just that old good time of PC, PC XT, PC AT etc.

I just was trying to say that using these old 8.3 names is a pain for me.
You are not able or not willing to understand that.

>> And it should be easy for Rob to fix it. Just compiling ec.ex with DJGPP
>> instead of Watcom probably should do the trick, see:
> 
> 
> <http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=> .. see next line
> 8&fromYear=A&toMonth=8&toYear=A&postedBy= .. see next line
> Juergen+Luethje&keywords=%222005+Aug+17+6%3A17%22>  ..
> 
> Ok, it is the end of your single word, Juergen ...  smile

Mmm? What does "end of your single word" mean?

> I see now what you do like to see ...    smile

I have said all the time clearly what I like to see:
A Euphoria DOS compiler that can handle files with long names when run in
a DOS window on Windows (because on plain DOS it is not possible at all).

And in the meantime I have learned that introducing long file names was
a great mistake, because it was the end of the "old good time". smile

<snip>

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

9. Re: Can't compile DOS program with long file name

Juergen Luethje wrote:
 
> Igor Kachan wrote:
> 
> > 
[snip]
> > Ok, it is not *too* excellent, it is just *almost* excellent.
> > It is just not that bad, I think now.
> 
> I'm glad that it is fine for you. However, that does not change the fact
> that it is everything else but excellent for me (as I wrote previously).

I'm sorry, you are right, I share your problem,
and it has 3 possible solutions:

1. Just now - just rename - just yours one.
2. Rob uses yours method about long names.
3. Rob abandones support for pure DOS.

As I'm an old lazy crazy, I vote for yours solution #1,
and it works just now, for you too (with some pain to you,
but what to do, I'm sorry, but this is the simplest way). 

> > I know that German language does allow very and very long
> > combined words, it is just a champion language about long
> > words, but me myself can not say something like to
> > 'ethyloxyethylparaphenilendiaminsulphate' without 5 breakes
> > in the middle of this not too long word.   smile
> 
> It does not matter whether or not I (or other Germans) can say so or not.
> I'm 48 years old, an not too silly. So rest assure that I know myself
> very well how to name my files properly.

Ok, you are right, I'm sorry, but please do not take all these
my 5 breakes too seriously, I just wanted to say that reading
of all these long names is my problem, I do not like long names
anyway, I like same libs for any and all platforms and try to
avoid long names in my own work.

Long names is my problem, I'm 60, lazy, and do not want
to type all these long names and then read them and search for
my typos.  

It was a good idea about long file names, but now you can meet
a file with content which is shorter than own file's name.

For example, one my file has name 'language.er' consists of
a single byte and takes 4K of an empty disk space on a FAT32 disk.

I'm sorry about all these my problems, you may skip them
without reading. 
 
> >> Since I always try to write code in include files as generic and
> >> cross-platform as possible, your suggestion means that I would have to
> >> rename all my .e library files, so that they only use old DOS 8.3 names.
> > 
> > Yes, if you want these libs to work on pure DOS, you have to
> > name them as 8.3.
> 
> Yes. But not if I use them in a DOS window on Windows. And it is _my_
> decision what I want to do, not yours or anyone else's.

Ok, I do understand yours decision and yours wish.
But for now it has some restriction, if you operate with ec.exe.
But me myself has the decisions and wishes *opposite* to yours ones.

What to do? I'm agreed with yours excellent for me solution #1.
Great #1 !!!   

> > The Watcom compiler cares about pure DOS.
> > This Open Watcom supports 16 bit DOS too.
> > 
> >> Just last week at work, I had to search for some old files (about 10
> >> years old) on CD, which all had 8.3 DOS names. It was a pain! I am very
> >> happy that we now can use more characters in order to give the files
> >> more meaningful names. I don't understand why I deliberately should want
> >> to do without it.
> > 
> > What to do, it is just that old good time of PC, PC XT, PC AT etc.
> 
> I just was trying to say that using these old 8.3 names is a pain for me.
> You are not able or not willing to understand that.

I do understand your pain very well, be sure, I'm sorry about
your pain, but I think this your pain is rare, not constant,
just sometimes. That was your first complaint about ec.exe.

And all pure DOS users do not have that pain at all, it is just
usual DOS life.

> >> And it should be easy for Rob to fix it. Just compiling ec.ex with DJGPP
> >> instead of Watcom probably should do the trick, see:
> > 
> > <<a
> > href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=</a>>
> > .. see next line
> > 8&fromYear=A&toMonth=8&toYear=A&postedBy= .. see next line
> > Juergen+Luethje&keywords=%222005+Aug+17+6%3A17%22>  ..
> > 
> > Ok, it is the end of your single word, Juergen ...  smile
> 
> Mmm? What does "end of your single word" mean?

On web interface, all these lines look just as a single word in a single line,
yours single word in German style, very long word, nothing more.

> > I see now what you do like to see ...    smile
> 
> I have said all the time clearly what I like to see:
> A Euphoria DOS compiler that can handle files with long names when run in
> a DOS window on Windows (because on plain DOS it is not possible at all).

Ok, I do understand you very well, but imagine please
yourself with this long-name-DOS32-program on plain DOS. 

ec.exe now automatically doesn't allow such a program.
And it is a good feature, I think.
With it, I'll have working programs for pure DOS and for DOS window,
and just now.
 
> And in the meantime I have learned that introducing long file names was
> a great mistake, because it was the end of the "old good time". smile

Not that great, not that mistake, but 8.3 names are not too bad,
they just remind us about that "old good time".   smile

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

10. Re: Can't compile DOS program with long file name

Igor & Juergen,

Open Watcom 1.5 will officially support full LFN on supported DOS versions. An
extention to the core Watcom libraries are under development. I do not think LFN
works on older DOS versions prior to 7.0 (Windows 95/98)? I'm not certain how the
development team is designing the libraries but do think it will use 8.3
truncated filenames if incompatible.

If RDS uses OW 1.5 then they should be able to extend their products for full
LFN. But then again the future of MS-DOS compatability on Windows is uncertain
and might not be worth the effort to implement.

I think RDS would be better off investing their time on porting their products
to the AMD64 platform and increasing the file size limits of Euphoria and EDS.


Regards,
Vincent

new topic     » goto parent     » topic index » view message » categorize

11. Re: Can't compile DOS program with long file name

Vincent wrote:

> Igor & Juergen,
> 
> Open Watcom 1.5 will officially support full LFN on supported DOS versions.
> An extention to the core Watcom libraries are under development. I do not
> think
> LFN works on older DOS versions prior to 7.0 (Windows 95/98)?

Normally, DOS LFN are only available when IFSMgr (i.e. Windows 95+) is
running. Otherwise they only can be accessed by using special TSR
programs.

> I'm not certain
> how the development team is designing the libraries but do think it will use
> 8.3 truncated filenames if incompatible.
> 
> If RDS uses OW 1.5 then they should be able to extend their products for full
> LFN. But then again the future of MS-DOS compatability on Windows is uncertain
> and might not be worth the effort to implement.

At the moment I'm not even asking for full DOS LFN support, but only for
ec.exe being able to translate program files with long names. I think
the effort to implement this will be little, just compile ec.ex with
DJGPP -- or with Open Watcom 1.5, as I learned from your post.

> I think RDS would be better off investing their time on porting their products
> to the AMD64 platform and increasing the file size limits of Euphoria and EDS.

Especially increasing the file size limits of Euphoria and EDS is also
on my wish list.

However, I have a problem with a discussion like this:
"I would like RDS to invest their time on implementing feature A instead
of feature B.".
Normally it is almost unpredictable what RDS will implement and what not.
So what if RDS will _not_ implement the desired feature A? Also, there is
the possibility that feature A _and_ feature B will be implemented.

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

12. Re: Can't compile DOS program with long file name

Igor Kachan wrote:

<snip>

> and it has 3 possible solutions:
> 
> 1. Just now - just rename - just yours one.
> 2. Rob uses yours method about long names.
> 3. Rob abandones support for pure DOS.

3. does not automatically fix the problem.

But the following probably does (as I wrote previousldy):
3. Compile ec.ex with DJGPP instead of old Watcom version.

And, according to Vincent's recent post:
4. Compile ec.ex with Watcom 1.5.

<snip>

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

13. Re: Can't compile DOS program with long file name

Juergen Luethje wrote:

> At the moment I'm not even asking for full DOS LFN support, but only for
> ec.exe being able to translate program files with long names. I think
> the effort to implement this will be little, just compile ec.ex with
> DJGPP -- or with Open Watcom 1.5, as I learned from your post.

Is it that simple though? He would at least need to make some changes with the C
header files and use the "-lfn" compiler option. If it's simple enough it might
be worth implementing full blown DOS LFN support.

> However, I have a problem with a discussion like this:
> "I would like RDS to invest their time on implementing feature A instead
> of feature B.".
> Normally it is almost unpredictable what RDS will implement and what not.
> So what if RDS will _not_ implement the desired feature A? Also, there is
> the possibility that feature A _and_ feature B will be implemented.

It doesnt matter what RDS implements so long it doesnt enable barriers on the
platforms I code for. I'm just saying RDS might be more interested in improving
their products on platforms of greater demand and market share.

> Regards,
>    Juergen


Regards,
Vincent

new topic     » goto parent     » topic index » view message » categorize

14. Re: Can't compile DOS program with long file name

Vincent wrote:

> Juergen Luethje wrote:
> 
>> At the moment I'm not even asking for full DOS LFN support, but only for
>> ec.exe being able to translate program files with long names. I think
>> the effort to implement this will be little, just compile ec.ex with
>> DJGPP -- or with Open Watcom 1.5, as I learned from your post.
> 
> Is it that simple though?

I'm not 100% sure, but I think chances are good, so it's worth a try.
As I understood Rob, the problem currently is creation of new files with
long names. The Eu DOS interpreter (as well as our own Eu programs compiled
with old Watcom) can't do so. But a Eu DOS program compiled with DJGPP
_can_ do so.

> He would at least need to make some changes with the
> C header files and use the "-lfn" compiler option. If it's simple enough it
> might be worth implementing full blown DOS LFN support.

According to this table:
<http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=A&toMonth=8&toYear=A&postedBy=Juergen+Luethje&keywords=%222005+Aug+17+6%3A17%22>

a Eu DOS program compiled with DJGPP automatically has almost complete
LFN support (with only one exception).

<snip>

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

15. Re: Can't compile DOS program with long file name

Vincent wrote:

> 
> Igor & Juergen,
> 
> Open Watcom 1.5 will officially support full LFN on supported DOS versions.
> An extention to the core Watcom libraries are under development. I do not
> think
> LFN works on older DOS versions prior to 7.0 (Windows 95/98)? I'm not certain
> how the development team is designing the libraries but do think it will use
> 8.3 truncated filenames if incompatible.

Ok, thanks, useful info, but what to LFN themselves, I do not like
them and almost never use them for my own files.

Why?

See please a screenshot of my Linux Mandrake 10.0 machine, it is 120K image:

http://www.private.peterlink.ru/kinz/long.png

It is a 'lib' directory. Just try to read the file names here
to see who is who.
Do you see the ppp.e Euphoria file?
And others, with long names?  
I'm afraid, sorry Juergen, I'd vote for 8.3 system of pure DOS, at least here! 
smile
 
> If RDS uses OW 1.5 then they should be able to extend their products for full
> LFN. But then again the future of MS-DOS compatability on Windows is uncertain
> and might not be worth the effort to implement.
> 
> I think RDS would be better off investing their time on porting their products
> to the AMD64 platform and increasing the file size limits of Euphoria and EDS.

All these things are just Rob's job, duty and business, I think.
Rob wants good Euphoria, I'm sure. And it is good now.
 
> Regards,
> Vincent

Regards,
Igor Kachan
kinz at peterlink.ru

new topic     » goto parent     » topic index » view message » categorize

16. Re: Can't compile DOS program with long file name

Igor Kachan wrote:

<snip>

> Ok, thanks, useful info, but what to LFN themselves, I do not like
> them and almost never use them for my own files.

<snip>

> I'm afraid, sorry Juergen, I'd vote for 8.3 system of pure DOS, at least here!
>  smile

<snip>

When a system supports long file names, that means that it provides the
_possibility_ to use them. But users are _not forced_ to use LFN. If you
want, you can give all your files 8.3 names on such a system.

Regards,
   Juergen

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu