X-DOS: anybody knows about it? (small free DOS)
salvador
I have a PC-104 device (9.5x9.5 cm PC for industrial purposes) with a very
strange DOS loaded. The name of this DOS is X-DOS, it is small (mem reports
618160 bytes of free memory) and is full of simple but useful details (i.e. the
SET command reports how big is the environment, how much is used and the
available space, dir uses colors, all helps are colored and interactive, etc).
This DOS seems to be done by Thierry Giron of HBS Corp. is dated in 1991 and
have quite nice features, one is integrated XMS driver (no device driver
needed), all the tools are compressed and command.com is 26281 bytes long.
I successfuly runned things like "redir -o test ls" and it works (seems to be
better than Win2k ;-). I also installed and runned my editor (a non-trivial
djgpp application).
I want to know if anybody uses it, until now I found only one incopatibility
with djgpp (I guess there are more). Is quite funny, but this DOS does *not*
invent the stupid ". " and ".." entries for the root directory, it makes my
editor to fail to display the contents of the root directory, ls also fails.
According to ls the error is EACCES and I think we should make libc more robust
about it.
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-...@bigfoot.com s...@computer.org
s...@ieee.org set-...@bigfoot.com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
Eli Zaretskii
On Wed, 2 Aug 2000, salvador wrote:
> I want to know if anybody uses it
I do use PC-104 on my daytime job, but with another OS. I don't know
anything about X-DOS.
> until now I found only one incopatibility
> with djgpp (I guess there are more). Is quite funny, but this DOS does *not*
> invent the stupid ". " and ".." entries for the root directory
No version of DOS known to me has the "." and ".." entries in the root
directory; try "dir c:\" and see. They are invented by the DJGPP
library inside the `readdir' function. The logic that decides whether
these two entries need to be faked is in the function
__set_need_fake_dot_dotdot that is defined on opendir.c in the
library. Perhaps that logic fails for some reason with this version
of DOS.
> it makes my
> editor to fail to display the contents of the root directory, ls also fails.
> According to ls the error is EACCES
I'm not sure this failure is due to those fake entries. Why should
the absence of "." cause directory listing to fail? Can you describe
more details (like what library function fails, and where exactly)?
Johan Henriksson
>the absence of "." cause directory listing to fail? Can you describe
>more details (like what library function fails, and where exactly)?
Don't know much about this topic but as an old lazy programmer I
would probably skip the two first dirs/files if I get them with
a certain compiler. If now another compiler doesn't give them,
well, you jump over two "real" dirs instead.
gde...@my-deja.com
> This DOS seems to be done by Thierry Giron of HBS Corp. is dated in 1991 [...]
Maybe it's the ancestor of the one cited here:
http://www.jkmicro.com/faq.html ?
JK Microsystems Flashlite Bios Version 1.3
JK Microsystems Embedded DOS Version 3.3a
(C) Copyright HBS Corp and JK Microsystems, Inc.
1991-1994, All Rights Reserved
HTH
______________________________________________________
Gautier -- http://members.xoom.com/gdemont/gsoft.htm
Sent via Deja.com http://www.deja.com/
Before you buy.
Eli Zaretskii
On Thu, 3 Aug 2000, Johan Henriksson wrote:
> Don't know much about this topic but as an old lazy programmer I
> would probably skip the two first dirs/files if I get them with
> a certain compiler.
That would be wrong: it is not guaranteed that the first two entries are
"." and ".." (although in practice I never saw anything else). You need
to look at the entry's name to know for sure. In particular, as I said,
root directories on DOS/Windows disks don't have these two entries.
> If now another compiler doesn't give them,
> well, you jump over two "real" dirs instead.
What new compiler?
The issue was how DJGPP library functions behave on XDOS as opposed to
other flavors of DOS. These are the same functions compiled with the
same compiler.
salvador
> SET:
> > This DOS seems to be done by Thierry Giron of HBS Corp. is dated in 1991 [...]
>
> Maybe it's the ancestor of the one cited here:
> http://www.jkmicro.com/faq.html ?
>
> JK Microsystems Flashlite Bios Version 1.3
> JK Microsystems Embedded DOS Version 3.3a
> (C) Copyright HBS Corp and JK Microsystems, Inc.
> 1991-1994, All Rights Reserved
Yes, this one wasn't modified by JK Microsystems. BTW, I got my DOM (Disk On Module)
preformated and with this OS already transferred, so they were bootable, that's
really nice
Evert Glebbeek
From: Eli Zaretskii <el...@is.elta.co.il>
On Thu, 3 Aug 2000 17:40:20 +0300 (IDT)
>That would be wrong: it is not guaranteed that the first two entries are
>"." and ".." (although in practice I never saw anything else).
I thought the ``.'' and ``..'' entries were created when the directory
is created and are thus the first two entries in the directory.
Johan Henriksson
>>"." and ".." (although in practice I never saw anything else).
>I thought the ``.'' and ``..'' entries were created when the directory
>is created and are thus the first two entries in the directory.
This is true for FATx (not root) and IIRC Ext2. But it is not always true.
Computer Gallery
example) has a "show dots off" command which kills the dots.
Thanks!
Phil
Johan Henriksson (j...@realsoftware.cjb.net) wrote:
: >>That would be wrong: it is not guaranteed that the first two entries are
Kurt McKee
implements '.' or '..', since the '.' means the current directory
(which can just be represented by '\' or '/' depending on your OS, dos
or linux), and you'll never find '..' on the root since '..' means
"parent directory". This is obviously impossible when at the root of
the drive!
-- Kurt McKee
On Wed, 02 Aug 2000 16:22:51 -0300, salvador <salv...@inti.gov.ar>
wrote:
>Hi All:
>
> I have a PC-104 device (9.5x9.5 cm PC for industrial purposes) with a very
>strange DOS loaded. The name of this DOS is X-DOS, it is small (mem reports
>618160 bytes of free memory) and is full of simple but useful details (i.e. the
>SET command reports how big is the environment, how much is used and the
>available space, dir uses colors, all helps are colored and interactive, etc).
> This DOS seems to be done by Thierry Giron of HBS Corp. is dated in 1991 and
>have quite nice features, one is integrated XMS driver (no device driver
>needed), all the tools are compressed and command.com is 26281 bytes long.
> I successfuly runned things like "redir -o test ls" and it works (seems to be
>better than Win2k ;-). I also installed and runned my editor (a non-trivial
>djgpp application).
> I want to know if anybody uses it, until now I found only one incopatibility
>with djgpp (I guess there are more). Is quite funny, but this DOS does *not*
>invent the stupid ". " and ".." entries for the root directory, it makes my
>editor to fail to display the contents of the root directory, ls also fails.
>According to ls the error is EACCES and I think we should make libc more robust
>about it.
>
>SET
>
>--
>Salvador Eduardo Tropea (SET). (Electronics Engineer)
>Visit my home page: http://welcome.to/SetSoft or
>http://www.geocities.com/SiliconValley/Vista/6552/
>Alternative e-mail: set-...@bigfoot.com s...@computer.org
> s...@ieee.org set-...@bigfoot.com
>Address: Curapaligue 2124, Caseros, 3 de Febrero
>Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
>
>
>
Visit me on the web at: truk (dot) wxs (dot) org
Eli Zaretskii
> Newsgroups: comp.os.msdos.djgpp
> Date: Thu, 17 Aug 2000 03:13:33 GMT
>
> As far as I know, you will never find a DOS of any sort that
> implements '.' or '..'
Actually, some network redirectors do implement these. I think some
of the CD-ROM formats also have these in the root directory.
> you'll never find '..' on the root since '..' means
> "parent directory". This is obviously impossible when at the root of
> the drive!
Of course, it's possile: just make ".." point to the root itself.
That's what Unix filesystems do, and that's what the DJGPP library's
emulation of "c:/.." does as well. It works so well that I'm guessing
no one until now was aware of that.