1. Bitten by a bug
Hi,
This may be known to some others, but I wasted some time figuring this out, so
I'm passing along the information.
There is a problem dividing atoms by a number that only showed up when the
program was compiled to C. In the process of clarifying it, I wrote this little
test program:
--------------------------------------------
--test.ex
--test effect of compiling using WATCOM C/C++ Version 11.0c
--run first without compiling, then with compiling
integer fn
atom x
puts(1,"Adding data to result.txt\n\n")
fn=open("c:\\euphoria\\result.txt","a")
puts(fn,"Test results for values of x (set at 75 before each operation)\n\n")
x=75
x=x/100
printf(fn,"With \"x=x/100\": x=%f\n",x)
x=75
x=x/100.0
printf(fn,"With \"x=x/100.0\": x=%f\n",x)
x=75
x/=100
printf(fn,"With \"x/=100\": x=%f\n",x)
x=75
x/=100.0
printf(fn,"With \"x/=100.0\": x=%f\n",x)
puts(fn,"\nEnd test results for values of x\n\n")
close(fn)
puts(1,"Done, any key...\n")
while equal(get_key(),-1) do end while
--------------------------------------------
The results were as follows:
First, without compiling the test program:
--------------------------------------------
Test results for values of x (set at 75 before each operation)
With "x=x/100": x=0.750000
With "x=x/100.0": x=0.750000
With "x/=100": x=0.750000
With "x/=100.0": x=0.750000
End test results for values of x
--------------------------------------------
Then, with compiling:
--------------------------------------------
Test results for values of x (set at 75 before each operation)
With "x=x/100": x=44169448.000000
With "x=x/100.0": x=0.750000
With "x/=100": x=44169452.000000
With "x/=100.0": x=0.750000
End test results for values of x
--------------------------------------------
Ironically, when I was trying to track down this bug, I tested for everything
but the real culprit, so lost some time...
--Quark
2. Re: Bitten by a bug
DB James wrote:
>
>
> Hi,
>
> This may be known to some others, but I wasted some time figuring this out,
> so I'm passing along the information.
>
> There is a problem dividing atoms by a number that only showed up when the
> program
> was compiled to C. In the process of clarifying it, I wrote this little test
> program:
>
> --------------------------------------------
> --test.ex
> --test effect of compiling using WATCOM C/C++ Version 11.0c
> --run first without compiling, then with compiling
> integer fn
> atom x
> puts(1,"Adding data to result.txt\n\n")
> fn=open("c:\\euphoria\\result.txt","a")
> puts(fn,"Test results for values of x (set at 75 before each operation)\n\n")
> x=75
> x=x/100
> printf(fn,"With \"x=x/100\": x=%f\n",x)
> x=75
> x=x/100.0
> printf(fn,"With \"x=x/100.0\": x=%f\n",x)
> x=75
> x/=100
> printf(fn,"With \"x/=100\": x=%f\n",x)
> x=75
> x/=100.0
> printf(fn,"With \"x/=100.0\": x=%f\n",x)
> puts(fn,"\nEnd test results for values of x\n\n")
> close(fn)
> puts(1,"Done, any key...\n")
> while equal(get_key(),-1) do end while
> --------------------------------------------
>
> The results were as follows:
>
> First, without compiling the test program:
>
> --------------------------------------------
> Test results for values of x (set at 75 before each operation)
>
> With "x=x/100": x=0.750000
> With "x=x/100.0": x=0.750000
> With "x/=100": x=0.750000
> With "x/=100.0": x=0.750000
>
> End test results for values of x
> --------------------------------------------
>
> Then, with compiling:
>
> --------------------------------------------
> Test results for values of x (set at 75 before each operation)
>
> With "x=x/100": x=44169448.000000
> With "x=x/100.0": x=0.750000
> With "x/=100": x=44169452.000000
> With "x/=100.0": x=0.750000
>
> End test results for values of x
> --------------------------------------------
>
> Ironically, when I was trying to track down this bug, I tested for everything
> but the real culprit, so lost some time...
>
> --Quark
>
I tried out and tested your program with the 2.5 official translator with Open
Watcom v1.4 beta (uncompressed EXE), and the program returned appended this into
Result.txt after two runs:
Test results for values of x (set at 75 before each operation)
With "x=x/100": x=0.750000
With "x=x/100.0": x=0.750000
With "x/=100": x=0.750000
With "x/=100.0": x=0.750000
End test results for values of x
Test results for values of x (set at 75 before each operation)
With "x=x/100": x=0.750000
With "x=x/100.0": x=0.750000
With "x/=100": x=0.750000
With "x/=100.0": x=0.750000
End test results for values of x
So it seems to be working fine for me... hmm, maybe you should try a newer
version of Watcom or another supported C compiler.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
3. Re: Bitten by a bug
Vincent wrote:
> I tried out and tested your program with the 2.5 official translator with Open
> Watcom v1.4 beta (uncompressed EXE), and the program returned appended this
> into Result.txt after two runs:
>
> Test results for values of x (set at 75 before each operation)
>
> With "x=x/100": x=0.750000
> With "x=x/100.0": x=0.750000
> With "x/=100": x=0.750000
> With "x/=100.0": x=0.750000
>
> End test results for values of x
>
> Test results for values of x (set at 75 before each operation)
>
> With "x=x/100": x=0.750000
> With "x=x/100.0": x=0.750000
> With "x/=100": x=0.750000
> With "x/=100.0": x=0.750000
>
> End test results for values of x
>
>
> So it seems to be working fine for me... hmm, maybe you should try a newer
> version
> of Watcom or another supported C compiler.
I just tried it using Watcom 10.6
(a version that's older than OpenWatcom 1.0)
and it worked fine on both DOS and Windows (ec and ecw).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Bitten by a bug
Vincent wrote:
SNIP
>
> I tried out and tested your program with the 2.5 official translator with Open
> Watcom v1.4 beta (uncompressed EXE), and the program returned appended this
> into Result.txt after two runs:
>
> Test results for values of x (set at 75 before each operation)
>
> With "x=x/100": x=0.750000
> With "x=x/100.0": x=0.750000
> With "x/=100": x=0.750000
> With "x/=100.0": x=0.750000
>
> End test results for values of x
>
> Test results for values of x (set at 75 before each operation)
>
> With "x=x/100": x=0.750000
> With "x=x/100.0": x=0.750000
> With "x/=100": x=0.750000
> With "x/=100.0": x=0.750000
>
> End test results for values of x
>
>
> So it seems to be working fine for me... hmm, maybe you should try a newer
> version
> of Watcom or another supported C compiler.
>
>
> Regards,
> Vincent
Hi, and thanks for checking this. I am using Eu 2.5, the free translator, and
WATCOM C/C++ Version 11.0c. I used that version because Robert mentioned: "It
has been tested with Watcom C/C++ 9.5, 10.6 and 11.0. Watcom is open source and
free." (Thought it would be safer to use the version of Watcom I did 
I may well install a newer version of Watcom soon, especially if any more bugs
pop up.
--Quark
5. Re: Bitten by a bug
Robert Craig wrote:
>
> Vincent wrote:
> > I tried out and tested your program with the 2.5 official translator with
> > Open
> > Watcom v1.4 beta (uncompressed EXE), and the program returned appended this
> > into Result.txt after two runs:
> >
> > Test results for values of x (set at 75 before each operation)
> >
> > With "x=x/100": x=0.750000
> > With "x=x/100.0": x=0.750000
> > With "x/=100": x=0.750000
> > With "x/=100.0": x=0.750000
> >
> > End test results for values of x
> >
> > Test results for values of x (set at 75 before each operation)
> >
> > With "x=x/100": x=0.750000
> > With "x=x/100.0": x=0.750000
> > With "x/=100": x=0.750000
> > With "x/=100.0": x=0.750000
> >
> > End test results for values of x
> >
> >
> > So it seems to be working fine for me... hmm, maybe you should try a newer
> > version
> > of Watcom or another supported C compiler.
>
> I just tried it using Watcom 10.6
> (a version that's older than OpenWatcom 1.0)
> and it worked fine on both DOS and Windows (ec and ecw).
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
As with Vincent, thanks for looking into this. Perhaps the little "c" at the
end of "WATCOM C/C++ Version 11.0c" stands for "caught ya"
--Quark
6. Re: Bitten by a bug
DB James wrote:
>
> Robert Craig wrote:
> >
> > Vincent wrote:
> > > I tried out and tested your program with the 2.5 official translator with
> > > Open
> > > Watcom v1.4 beta (uncompressed EXE), and the program returned appended
> > > this
> > > into Result.txt after two runs:
> > >
> > > Test results for values of x (set at 75 before each operation)
> > >
> > > With "x=x/100": x=0.750000
> > > With "x=x/100.0": x=0.750000
> > > With "x/=100": x=0.750000
> > > With "x/=100.0": x=0.750000
> > >
> > > End test results for values of x
> > >
> > > Test results for values of x (set at 75 before each operation)
> > >
> > > With "x=x/100": x=0.750000
> > > With "x=x/100.0": x=0.750000
> > > With "x/=100": x=0.750000
> > > With "x/=100.0": x=0.750000
> > >
> > > End test results for values of x
> > >
> > >
> > > So it seems to be working fine for me... hmm, maybe you should try a newer
> > > version
> > > of Watcom or another supported C compiler.
> >
> > I just tried it using Watcom 10.6
> > (a version that's older than OpenWatcom 1.0)
> > and it worked fine on both DOS and Windows (ec and ecw).
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> >
>
> As with Vincent, thanks for looking into this. Perhaps the little "c" at the
> end of "WATCOM C/C++ Version 11.0c" stands for "caught ya"
>
> --Quark
>
Although I still haven't bothered with translating/compiling, I've never had
problems with the compiler offered by http://www.mingw.org/ (experience limited,
but always without issue). I still don't understand why it's not supported.
Could it possibly be too much trouble? Can I assist you in testing it Robert?
If a Multiple Arcade Machine Emulator can be compiled using it, it can't be all
that bad, epecially speed-wise.
I don't ask much and I offer assistance...
-- Brian
7. Re: Bitten by a bug
- Posted by Robert Craig <rds at RapidEuphoria.com>
Oct 19, 2005
-
Last edited Oct 20, 2005
DB James wrote:
> As with Vincent, thanks for looking into this. Perhaps the little "c" at the
> end of "WATCOM C/C++ Version 11.0c" stands for "caught ya"
It sounds like WATCOM 11.0c has a bug, but I've also
seen cases where someone submits a slightly incorrect
program to the translator, and it runs without an error
message because translated code has very few error checks.
The person then runs the program with the interpreter
and the interpreter catches a small error like type_check
failure. The person corrects the type of a variable
and then discovers that his .exe built from the translator
does not run the same as when he uses the interpreter.
i.e. you might want to delete your result.txt file, rebuild
your .exe and go through it again carefully.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Bitten by a bug
- Posted by Robert Craig <rds at RapidEuphoria.com>
Oct 19, 2005
-
Last edited Oct 20, 2005
Brian Broker wrote:
> Although I still haven't bothered with translating/compiling, I've never had
> problems with the compiler offered
> by <a href="http://www.mingw.org/">http://www.mingw.org/</a> (experience
> limited, but always without issue). I
> still don't understand why it's not supported. Could it possibly be too much
> trouble? Can I assist you in testing
> it Robert?
The Translator already supports 3 different Windows C compilers
(not to mention 2 for DOS, and GCC for Linux and FreeBSD)
I don't see much value in supporting a 4th compiler for Windows.
Watcom and Borland are both very reliable compilers that
produce fast machine code. Supporting an additional compiler
takes a fair bit of work, both initially, and then later as
people start reporting real or imagined compiler-specific bugs.
And what do you gain? It just means those who already have the
4th compiler installed won't have to install one of the other 3.
> If a Multiple Arcade Machine Emulator can be compiled using it, it can't be
> all that bad, epecially speed-wise.
>
> I don't ask much and I offer assistance...
I appreciate the offer, but I don't want to support
another compiler for an already-supported platform,
unless maybe it's Microsoft C/C++.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Bitten by a bug
Robert Craig wrote:
>
> Brian Broker wrote:
> > Although I still haven't bothered with translating/compiling, I've never had
> > problems
> with the compiler offered</font></i>
> > by <a href="http://www.mingw.org/">http://www.mingw.org/</a> (experience
> > limited, but
> always without issue). I</font></i>
> > still don't understand why it's not supported. Could it possibly be too
> > much trouble?
> Can I assist you in testing</font></i>
> > it Robert?
>
> The Translator already supports 3 different Windows C compilers
> (not to mention 2 for DOS, and GCC for Linux and FreeBSD)
> I don't see much value in supporting a 4th compiler for Windows.
> Watcom and Borland are both very reliable compilers that
> produce fast machine code. Supporting an additional compiler
> takes a fair bit of work, both initially, and then later as
> people start reporting real or imagined compiler-specific bugs.
> And what do you gain? It just means those who already have the
> 4th compiler installed won't have to install one of the other 3.
>
> > If a Multiple Arcade Machine Emulator can be compiled using it, it can't be
> > all that bad, epecially speed-wise.
> >
> > I don't ask much and I offer assistance...
>
> I appreciate the offer, but I don't want to support
> another compiler for an already-supported platform,
> unless maybe it's Microsoft C/C++.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
The only thing that I would add to this is that mingw is a win32 port of gcc so
it wouldn't *really* be like adding another compiler. It would just be making
sure that mingw worked with the translator. Doesn't the translator already work
with djgpp? I don't think that it would be that much more work.
I think it would be great to drop support for lcc and add support for Digital
Mars C compiler, but I know that probably *is* a lot more work.
j.
10. Re: Bitten by a bug
Robert Craig wrote:
>
> DB James wrote:
> > As with Vincent, thanks for looking into this. Perhaps the little "c" at
> > the
> > end of "WATCOM C/C++ Version 11.0c" stands for "caught ya"
>
> It sounds like WATCOM 11.0c has a bug, but I've also
> seen cases where someone submits a slightly incorrect
> program to the translator, and it runs without an error
> message because translated code has very few error checks.
> The person then runs the program with the interpreter
> and the interpreter catches a small error like type_check
> failure. The person corrects the type of a variable
> and then discovers that his .exe built from the translator
> does not run the same as when he uses the interpreter.
> i.e. you might want to delete your result.txt file, rebuild
> your .exe and go through it again carefully.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Hello Robert,
I agree that a test should be done carefully, as the purpose of a test is to be
as sure as possible about something. I did as you suggested, deleted both
result.txt and the old compiled version of the test, ran the test program from
the interpreter, then compiled the test program and immediately ran it. Here are
the results, the same as I reported before:
----------------------------------------------------------------------
Test results for values of x (set at 75 before each operation)
With "x=x/100": x=0.750000
With "x=x/100.0": x=0.750000
With "x/=100": x=0.750000
With "x/=100.0": x=0.750000
End test results for values of x
Test results for values of x (set at 75 before each operation)
With "x=x/100": x=44169448.000000
With "x=x/100.0": x=0.750000
With "x/=100": x=44169452.000000
With "x/=100.0": x=0.750000
End test results for values of x
----------------------------------------------------------------------
So, it does seem to be a real bug in the WATCOM C/C++ Version 11.0c compiler.
FYI,there is this tidbit from the readme.txt for the compiler:
----------------------------------------------------------------------
All files licensed by Microsoft, IBM, Novell, Tenberry,
Pharlap and Blue Sky Software have been removed in this version.
The Windows SDK components and Microsoft Foundation Classes are
not included in the 11.0c update. If you wish to do Windows
programming you are required to have a prior version of Watcom
C/C++ 11.0, especially for MFC support. Watcom C/C++ 10.6 may
work, but this has not been tested.
----------------------------------------------------------------------
I'll be installing a later version of the Watcom compiler soon.
--Quark
11. Re: Bitten by a bug
DB James wrote:
> So, it does seem to be a real bug in the WATCOM C/C++ Version 11.0c compiler.
>
> FYI,there is this tidbit from the readme.txt for the compiler:
>
> ----------------------------------------------------------------------
> All files licensed by Microsoft, IBM, Novell, Tenberry,
> Pharlap and Blue Sky Software have been removed in this version.
>
> The Windows SDK components and Microsoft Foundation Classes are
> not included in the 11.0c update. If you wish to do Windows
> programming you are required to have a prior version of Watcom
> C/C++ 11.0, especially for MFC support. Watcom C/C++ 10.6 may
> work, but this has not been tested.
> ----------------------------------------------------------------------
>
> I'll be installing a later version of the Watcom compiler soon.
OK, thanks.
I suspect that version of Watcom was not tested by many people,
since you had to already own a copy of the commercial version of Watcom.
i.e. It wasn't completely free and open source.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
12. Re: Bitten by a bug
Jason Gade wrote:
> The only thing that I would add to this is that mingw is a win32 port of gcc
> so it wouldn't *really* be like adding another compiler. It would just be
> making
> sure that mingw worked with the translator.
> Doesn't the translator already work
> with djgpp?
Yes, on DOS.
> I don't think that it would be that much more work.
>
> I think it would be great to drop support for lcc and add support for Digital
> Mars C compiler, but I know that probably *is* a lot more work.
It's hard to say how much work it will be until you get half way
through it. There are lots of small incompatibilities among
C compilers. If a critical C library routine is missing or
works very differently, it can require a lot of time to work around it.
Things like dir() can be tough.
Then there are the calls from Euphoria to C which require intimate
knowledge of the call stack etc. Sometimes the malloc's are very
different which might require some drastic changes since Euphoria
is a "power user" of malloc, i.e. it knows more about
the internals of malloc than it really should. In general it means
adding lots of #ifdef's to code that is already packed with them.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: Bitten by a bug
Robert Craig wrote:
>
> Jason Gade wrote:
> > The only thing that I would add to this is that mingw is a win32 port of gcc
> > so it wouldn't *really* be like adding another compiler. It would just be
> > making
> > sure that mingw worked with the translator.
> > Doesn't the translator already work
> > with djgpp?
>
> Yes, on DOS.
<snipped other compiler difficulties>
Okay. I thought it would be difficult to move to another compiler. But since
mingw is gcc for Windows vs. djgpp is gcc for DOS, how difficult would that be?
I'm asking because I don't know how difficult it would be for the same compiler
under different platforms. If you wouldn't know until you got halfway through
then nevermind.
I don't suppose there is a way to make the translator's code more portable
between platforms so that it is less compiler-specific?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
j.
14. Re: Bitten by a bug
Robert Craig wrote:
>
> Jason Gade wrote:
> > The only thing that I would add to this is that mingw is a win32 port of gcc
> > so it wouldn't *really* be like adding another compiler. It would just be
> > making
> > sure that mingw worked with the translator.
> > Doesn't the translator already work
> > with djgpp?
>
> Yes, on DOS.
>
> > I don't think that it would be that much more work.
> >
> > I think it would be great to drop support for lcc and add support for
> > Digital
> > Mars C compiler, but I know that probably *is* a lot more work.
>
> It's hard to say how much work it will be until you get half way
> through it. There are lots of small incompatibilities among
> C compilers. If a critical C library routine is missing or
> works very differently, it can require a lot of time to work around it.
> Things like dir() can be tough.
> Then there are the calls from Euphoria to C which require intimate
> knowledge of the call stack etc. Sometimes the malloc's are very
> different which might require some drastic changes since Euphoria
> is a "power user" of malloc, i.e. it knows more about
> the internals of malloc than it really should. In general it means
> adding lots of #ifdef's to code that is already packed with them.
>
I think if you do anything, it should be to make Borland 100% compatable with
the Euphoria, like Watcom and GCC. The last time I tried Borland 5.5 with the
Euphoria to C translator v2.4 I had a hell of a time trying to get the
enviromental variables set, but once I did though, I did a test compile with
window.exw or winwire.exw (I forgot which); it translated/compiled, but when I
ran it, I got a machine exception. They both worked fine with OpenWatcom.
Perhaps it's better now with v2.5, I havent tried. But since then I've came to
the conclusion that 99 percent compatable just isnt good enough in some cases and
that only perfect is.
Maybe you can do some testing with it to see if you can reproduce the problem
with the 2.5 translator.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
15. Re: Bitten by a bug
Vincent wrote:
> I think if you do anything, it should be to make Borland 100% compatable with
> the Euphoria, like Watcom and GCC. The last time I tried Borland 5.5 with the
> Euphoria to C translator v2.4 I had a hell of a time trying to get the
> enviromental
> variables set, but once I did though, I did a test compile with window.exw or
> winwire.exw (I forgot which); it translated/compiled, but when I ran it, I got
> a machine exception. They both worked fine with OpenWatcom.
>
> Perhaps it's better now with v2.5, I havent tried. But since then I've came
> to the conclusion that 99 percent compatable just isnt good enough in some
> cases
> and that only perfect is.
>
> Maybe you can do some testing with it to see if you can reproduce the problem
> with the 2.5 translator.
window.exw and winwire.exw both run fine when translated/compiled
with the 2.5 translator and Borland. It's not convenient for me
to try 2.4 right now.
When I say that Borland is 99% compatible, I'm just referring
to fairly trivial differences. I don't recall exactly, but
some of the details reported by dir() might be a bit different
for example. You aren't likely to get a crash because you used
Borland rather than Watcom (unless there's an error in your code,
such as not declaring a .dll routine as CDECL.)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Bitten by a bug
Jason Gade wrote:
> I don't suppose there is a way to make the translator's code more portable
> between
> platforms so that it is less compiler-specific?
90% of the translator is independent of platform and C compiler.
I don't see any magic way to make things a lot more independent.
Anyway most of the problems arise in building the translator
library, rather than in the translator itself. The library
source is riddled with #ifdef statements to handle differences
between the various compilers and platforms. It's hard to avoid it.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
17. Re: Bitten by a bug
> When I say that Borland is 99% compatible, I'm just referring
> to fairly trivial differences. I don't recall exactly, but
> some of the details reported by dir() might be a bit different
> for example. You aren't likely to get a crash because you used
> Borland rather than Watcom (unless there's an error in your code,
> such as not declaring a .dll routine as CDECL.)
Euman pointed this out. He never said specifically what it was, but if
you use my win_dir() routine, you'll have no issues, since my
win_dir() routine is just a portable version of his dir95() routine.
~Greg
