Hi Eric and Bart,
yes, upcasing filenames in dos_open() is not a problem. I'll add that in =
my port.
The port status is the following:
1. dos_open(), dos_close(), (*) dos_read(), (*) dos_write() work. I still=
need to write some more test cases, but I'm quite sure that the FAT calc=
ulations are correct :-)
2. During the weekend I'm gonna port the other system calls:
dos_lseek(), dos_rename(), ...
3. By the end of june, I'm gonna port: dos_cd(), dos_mkdir(), dos_rmdir()=
, ...
After that, I'm gonna test the code on a FAT32 disk and
then, I'm gonna try to add LFN support according to the Microsoft's docum=
ent fatgen103.pdf.
So far, I did not add a single line of code :-)
I just commented out some lines of code, commented out keywords like FAR,=
REG,... , and written the device driver to access physical drives on Win=
dows XP.
Enrico
> On 5/29/07, Eric Auer <eric@...> wrote:
> > > there are no "toupper" or similar function calls from dos_open()
> > > down to exechr().
> >
> > This is because the case (in) sensitivity handling happens in
> > DosOpenSft which in turn calls dos_open. So dos_open is one
> > step too "lowlevel" to be case insensitive. Other functions
> > seem to call truename to preprocess filenames a bit...?
>
> Yes indeed: the Dos* functions call truename to convert the
> user-provided pathname to a "fully-qualified" name in the SDA (DOS
> data). This name has no . or .., always has a drive letter, and is
> always uppercased (except for UNC pathnames \\SHARE\... which don't
> have a drive letter).
>
> The dos_* functions in fatfs.c expect such canonical pathnames, just
> like the redirector functions (INT2F/11xx, used by *CDEX, network file
> systems, etc.) do.
>
> Bart
=0A=0A=0A------------------------------------------------------=0ALeggi G=
RATIS le tue mail con il telefonino i-mode=99 di Wind=0Ahttp://i-mode.win=
d.it/=0A

On 5/29/07, Eric Auer <eric@...> wrote:
> > there are no "toupper" or similar function calls from dos_open()
> > down to exechr().
>
> This is because the case (in) sensitivity handling happens in
> DosOpenSft which in turn calls dos_open. So dos_open is one
> step too "lowlevel" to be case insensitive. Other functions
> seem to call truename to preprocess filenames a bit...?
Yes indeed: the Dos* functions call truename to convert the
user-provided pathname to a "fully-qualified" name in the SDA (DOS
data). This name has no . or .., always has a drive letter, and is
always uppercased (except for UNC pathnames \\SHARE\... which don't
have a drive letter).
The dos_* functions in fatfs.c expect such canonical pathnames, just
like the redirector functions (INT2F/11xx, used by *CDEX, network file
systems, etc.) do.
Bart

Hi Enrico,
> there are no "toupper" or similar function calls from dos_open()
> down to exechr().
This is because the case (in) sensitivity handling happens in
DosOpenSft which in turn calls dos_open. So dos_open is one
step too "lowlevel" to be case insensitive. Other functions
seem to call truename to preprocess filenames a bit...? One
example for this is DosGetFattr. Maybe you want to add some
parts or all of the truename function to your FAT driver lib.
Eric

Hi Enrico,
> I noticed that in this version of FreeDOS, the function:
> Upmem (unsigned char* str, unsigned int len)
> is missing and the filesystem seems case sensitive.
> I indeed can't open an existing file, named "foo.txt", when I call:
> dos_open ("Foo.txt,..,..);
Interesting. There are various "to upper case" functions in use:
strupr - to upper case plain ASCII things in config sys, like
device driver args and env var names.
DosUpFMem - used in DeviceOpenSft but not in DosOpenSft
... otoh, truename calls DosUpFString at some point
upMMem - only used in nls(F)UpMem for NLS functions
DosUpFString - used in truename, simple DosUpFMem wrapper
So at first glance DosOpenSft seems to call a DosUpF* function
as needed, but your dos_open experiment fails. Maybe somebody
else can tell what is going wrong here?
Eric

ok, doing it now.
On 5/22/07, Bart Oldeman <bartoldeman@...> wrote:
> On 5/16/07, Jim Hall <jhall@...> wrote:
> > I haven't seen any replies in this thread that argue Subversion is a
> > bad idea, but let's make this a FINAL CALL before we go ahead. If no
> > one speaks up by this time tomorrow, I think Bart gets the go-ahead to
> > convert the FreeDOS CVS to Subversion on SourceForge.
> >
> > When did you plan to do the conversion? This weekend, I assume?
>
> Well, right now the CVS stable kernel is updated with both Eric's and
> Tom's changes (at least those that were made public) so this looks
> like a good point.
>
> I uploaded a (14MB) svndump.bz2 file to
> /home/groups/f/fr/freedos/htdocs/kernel/svndump.bz2
> on shell.sourceforge.net, but someone else (Aitor, Eric, Jeremy, or
> Jim) will need to follow the instructions at
> http://sourceforge.net/docs/E09#import
> as I don't have permissions to do that.
>
> To be specific:
> mv /home/groups/f/fr/freedos/htdocs/kernel/svndump.bz2
> /home/groups/f/fr/freedos/svndump.bz2
>
> and then start at Import from Subversion dump file (svnadmin dump or
> cvs2svn): #6.
>
> Bart
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

On 5/16/07, Jim Hall <jhall@...> wrote:
> I haven't seen any replies in this thread that argue Subversion is a
> bad idea, but let's make this a FINAL CALL before we go ahead. If no
> one speaks up by this time tomorrow, I think Bart gets the go-ahead to
> convert the FreeDOS CVS to Subversion on SourceForge.
>
> When did you plan to do the conversion? This weekend, I assume?
Well, right now the CVS stable kernel is updated with both Eric's and
Tom's changes (at least those that were made public) so this looks
like a good point.
I uploaded a (14MB) svndump.bz2 file to
/home/groups/f/fr/freedos/htdocs/kernel/svndump.bz2
on shell.sourceforge.net, but someone else (Aitor, Eric, Jeremy, or
Jim) will need to follow the instructions at
http://sourceforge.net/docs/E09#import
as I don't have permissions to do that.
To be specific:
mv /home/groups/f/fr/freedos/htdocs/kernel/svndump.bz2
/home/groups/f/fr/freedos/svndump.bz2
and then start at Import from Subversion dump file (svnadmin dump or
cvs2svn): #6.
Bart

Florian Xaver wrote:
> A DOS version of CVS exists...of Subversion too?
Bart already wrote:
"Another thing that may annoy some is that there exists no SVN client
for DOS. On the other hand, there exists no network aware CVS client
either... so I don't think anyone has ever checked out CVS sources
from SF on DOS. Thus this is more of a theoretical issue."
Robert Riebisch
--
BTTR Software
http://www.bttr-software.de/

Hi Eric,
I'm porting the following function:
int rqblockio (unsigned char command, struct dpb *dpbp);
In particular, the command I need to emulate is:
C_BLDBPB (which builds the Bios Parameter Block)
to do that, I'm gonna:
1. Read the boot sector of the volume
2. Make some calculations
3. Fill the fields of dpb (disk parameter block)
The dpb has the following field: "dpb_nfreeclst" which is the number of f=
ree clusters of the volume.
How am I supposed to calculate "dpb_nfreeclst"?
The boot sector, in fact, contains the number of "available" clusters but=
not of "free_clusters".
Is "dpb_nfreeclst" really needed by FreeDOS?
thanks for your support,
Enrico
=0A=0A=0A------------------------------------------------------=0APassa a=
Infostrada. ADSL e Telefono senza limiti e senza canone Telecom=0Ahttp:/=
/click.libero.it/infostrada=0A

PS:
A DOS version of CVS exists...of Subversion too?
--
It is true that no one can essentially cultivate exact science
without understanding the mathematics of that science. But we are not
to suppose that the calculations and equations that mathematicians
find so useful constitute the whole of mathematics. The calculus is but
a part of mathematics.
(James Clerk Maxwell)
Using Arachne, the GPL Web Browser/Suite

Hi,
is CVS really used at the moment? I thought, that most people have
sent patches to current "maintainer".
Bye
Flo
On 5/16/07, Jim Hall <jhall@...> wrote:
> I haven't seen any replies in this thread that argue Subversion is a
> bad idea, but let's make this a FINAL CALL before we go ahead. If no
> one speaks up by this time tomorrow, I think Bart gets the go-ahead to
> convert the FreeDOS CVS to Subversion on SourceForge.
>
> When did you plan to do the conversion? This weekend, I assume?
> (I'll want to be sure to make note of it on the web site.)
>
> -jh
>
>
> On 5/15/07, Bart Oldeman <bartoldeman@...> wrote:
> > On 5/15/07, Jim Hall <jhall@...> wrote:
> > > I have no objection to SVN, but I haven't edited any sources in a
> > > while so maybe I'm not a good person to chime in. :-)
> > >
> > > If we do decide to migrate to Subversion, we should use the SVN
> > > repository on SourceForge (it's not activated yet, but it's there to
> > > be used.) This helps to keep all FreeDOS-related resources in one
> > > place.
> >
> > yes, of course, that's the idea. Also, to have the directories
> > structured like this:
> >
> > root
> > \kernel\trunk
> > \branches\UNSTABLE
> > \jhall
> > \tags\....
> > \freecom\trunk
> > \...
> > \install\...
> > \mem\...
> >
> > instead of the default you'd get from cvs2svn that looks like this:
> >
> > root
> > \trunk\kernel
> > \freecom
> > \...
> > \branches\UNSTABLE
> > \jhall
> > \jimtabor
> > \expExec
> > \...
> > \tags\com083beta7
> > \ke2035a
> > \...
> >
> > The problem is that in this default layout all branches are lumped
> > together without you always knowing if it's freecom or kernel without
> > looking inside
> >
> > well, I can provide a dump file if it gets the go ahead.
> >
> > Bart
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
--
It is true that no one can essentially cultivate exact science
without understanding the mathematics of that science. But we are not
to suppose that the calculations and equations that mathematicians
find so useful constitute the whole of mathematics. The calculus is but
a part of mathematics.
(James Clerk Maxwell)
Using Arachne, the GPL Web Browser/Suite

I haven't seen any replies in this thread that argue Subversion is a
bad idea, but let's make this a FINAL CALL before we go ahead. If no
one speaks up by this time tomorrow, I think Bart gets the go-ahead to
convert the FreeDOS CVS to Subversion on SourceForge.
When did you plan to do the conversion? This weekend, I assume?
(I'll want to be sure to make note of it on the web site.)
-jh
On 5/15/07, Bart Oldeman <bartoldeman@...> wrote:
> On 5/15/07, Jim Hall <jhall@...> wrote:
> > I have no objection to SVN, but I haven't edited any sources in a
> > while so maybe I'm not a good person to chime in. :-)
> >
> > If we do decide to migrate to Subversion, we should use the SVN
> > repository on SourceForge (it's not activated yet, but it's there to
> > be used.) This helps to keep all FreeDOS-related resources in one
> > place.
>
> yes, of course, that's the idea. Also, to have the directories
> structured like this:
>
> root
> \kernel\trunk
> \branches\UNSTABLE
> \jhall
> \tags\....
> \freecom\trunk
> \...
> \install\...
> \mem\...
>
> instead of the default you'd get from cvs2svn that looks like this:
>
> root
> \trunk\kernel
> \freecom
> \...
> \branches\UNSTABLE
> \jhall
> \jimtabor
> \expExec
> \...
> \tags\com083beta7
> \ke2035a
> \...
>
> The problem is that in this default layout all branches are lumped
> together without you always knowing if it's freecom or kernel without
> looking inside
>
> well, I can provide a dump file if it gets the go ahead.
>
> Bart
>

On 5/15/07, Jim Hall <jhall@...> wrote:
> I have no objection to SVN, but I haven't edited any sources in a
> while so maybe I'm not a good person to chime in. :-)
>
> If we do decide to migrate to Subversion, we should use the SVN
> repository on SourceForge (it's not activated yet, but it's there to
> be used.) This helps to keep all FreeDOS-related resources in one
> place.
yes, of course, that's the idea. Also, to have the directories
structured like this:
root
\kernel\trunk
\branches\UNSTABLE
\jhall
\tags\....
\freecom\trunk
\...
\install\...
\mem\...
instead of the default you'd get from cvs2svn that looks like this:
root
\trunk\kernel
\freecom
\...
\branches\UNSTABLE
\jhall
\jimtabor
\expExec
\...
\tags\com083beta7
\ke2035a
\...
The problem is that in this default layout all branches are lumped
together without you always knowing if it's freecom or kernel without
looking inside
well, I can provide a dump file if it gets the go ahead.
Bart

On 5/15/07, Aitor Santamar=EDa <aitor.sm@...> wrote:
> I'm just curious, as I have never used much of cvs and none of SVN
> (just MS Sourcesafe, pvcs and other commercial solutions), what would
> be the main advantages of SVN to CVS?
Losing the line-ending annoyance for one... there are other advantages
though, like off-line diffing, status and revert commands (in CVS you
need to do "rm file; cvs up file" to revert). There is a revision
number after each commit so it is straight forward to do a binary
search between commits in case there is a regression. And so on.
> (in other words, why would you care to make such a big effort?
well if it was a really big effort I wouldn't put it up. But it isn't.
There are automated conversion tools, and for people who understand
basic CVS, SVN is very easy to learn (basic usage is similar, it was
designed to be a "better CVS").
Bart

I'm just curious, as I have never used much of cvs and none of SVN
(just MS Sourcesafe, pvcs and other commercial solutions), what would
be the main advantages of SVN to CVS?
(in other words, why would you care to make such a big effort?
probably there are many good reasons, then).
Aitor
2007/5/15, Bart Oldeman <bartoldeman@...>:
> Hi,
>
> would people here support a conversion of the FreeDOS CVS repository
> (kernel, freecom, install, mem) to Subversion (SVN)? One big plus is
> that CRLF problems would be mostly a thing of the past... what has
> happened a lot is that people check out CVS files on *nix, get LF line
> endings, correct them to CRLF, check them back in, people on Windows
> check them out, see CRCRLF nonsense line ending, correct them, check
> them back in, and the game continues. Or files in .zip files get the
> wrong line endings, etc. With Subversion, you can specify a CRLF line
> ending for all text files so these things won't happen. I've used
> Subversion for a while with DOSEMU and it works well.
>
> I must say (from private mail) that Eric would rather stay with CVS
> because of unfamiliarity with SVN and the fact that the working
> directories take up twice the space (ie. 4MB instead of 2 for the
> kernel for instance). The extra space comes from the caching of the
> repository contents locally, which has its advantages too because an
> "svn diff" or "svn revert" does not need to contact the server.
>
> Another thing that may annoy some is that there exists no SVN client
> for DOS. On the other hand, there exists no network aware CVS client
> either... so I don't think anyone has ever checked out CVS sources
> from SF on DOS. Thus this is more of a theoretical issue.
>
> What do others think? I'd be happy to do the conversion myself.
> Bart
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

I have no objection to SVN, but I haven't edited any sources in a
while so maybe I'm not a good person to chime in. :-)
If we do decide to migrate to Subversion, we should use the SVN
repository on SourceForge (it's not activated yet, but it's there to
be used.) This helps to keep all FreeDOS-related resources in one
place.
-jh
On 5/15/07, Lyrical Nanoha <lyricalnanoha@...> wrote:
> On Tue, 15 May 2007, Bart Oldeman wrote:
>
> > Hi,
> >
> > would people here support a conversion of the FreeDOS CVS repository
> > (kernel, freecom, install, mem) to Subversion (SVN)? One big plus is
> > that CRLF problems would be mostly a thing of the past... what has
> > happened a lot is that people check out CVS files on *nix, get LF line
> > endings, correct them to CRLF, check them back in, people on Windows
> > check them out, see CRCRLF nonsense line ending, correct them, check
> > them back in, and the game continues. Or files in .zip files get the
> > wrong line endings, etc. With Subversion, you can specify a CRLF line
> > ending for all text files so these things won't happen. I've used
> > Subversion for a while with DOSEMU and it works well.
> >
> > I must say (from private mail) that Eric would rather stay with CVS
> > because of unfamiliarity with SVN and the fact that the working
> > directories take up twice the space (ie. 4MB instead of 2 for the
> > kernel for instance). The extra space comes from the caching of the
> > repository contents locally, which has its advantages too because an
> > "svn diff" or "svn revert" does not need to contact the server.
> >
> > Another thing that may annoy some is that there exists no SVN client
> > for DOS. On the other hand, there exists no network aware CVS client
> > either... so I don't think anyone has ever checked out CVS sources
> > from SF on DOS. Thus this is more of a theoretical issue.
> >
> > What do others think? I'd be happy to do the conversion myself.
> > Bart
>
> I never really figured out cvs but I think I got the hang of svn pretty
> well. If it would fix problems with the current system, without
> introducing much of its own - and that seems to be the case from what
> little I know of it - I say go for it (n/m that my initials are ALSO
> "SVN")...
>
> -uso.
>

On Tue, 15 May 2007, Bart Oldeman wrote:
> Hi,
>
> would people here support a conversion of the FreeDOS CVS repository
> (kernel, freecom, install, mem) to Subversion (SVN)? One big plus is
> that CRLF problems would be mostly a thing of the past... what has
> happened a lot is that people check out CVS files on *nix, get LF line
> endings, correct them to CRLF, check them back in, people on Windows
> check them out, see CRCRLF nonsense line ending, correct them, check
> them back in, and the game continues. Or files in .zip files get the
> wrong line endings, etc. With Subversion, you can specify a CRLF line
> ending for all text files so these things won't happen. I've used
> Subversion for a while with DOSEMU and it works well.
>
> I must say (from private mail) that Eric would rather stay with CVS
> because of unfamiliarity with SVN and the fact that the working
> directories take up twice the space (ie. 4MB instead of 2 for the
> kernel for instance). The extra space comes from the caching of the
> repository contents locally, which has its advantages too because an
> "svn diff" or "svn revert" does not need to contact the server.
>
> Another thing that may annoy some is that there exists no SVN client
> for DOS. On the other hand, there exists no network aware CVS client
> either... so I don't think anyone has ever checked out CVS sources
> from SF on DOS. Thus this is more of a theoretical issue.
>
> What do others think? I'd be happy to do the conversion myself.
> Bart
I never really figured out cvs but I think I got the hang of svn pretty
well. If it would fix problems with the current system, without
introducing much of its own - and that seems to be the case from what
little I know of it - I say go for it (n/m that my initials are ALSO
"SVN")...
-uso.
-----------------------------------------------------------
There are four boxes to use in the defense of liberty:
Soap, Ballot, Jury, Ammo.
Use in that order, starting now.
-- Attr. to Ed Howdershelt

Hi,
would people here support a conversion of the FreeDOS CVS repository
(kernel, freecom, install, mem) to Subversion (SVN)? One big plus is
that CRLF problems would be mostly a thing of the past... what has
happened a lot is that people check out CVS files on *nix, get LF line
endings, correct them to CRLF, check them back in, people on Windows
check them out, see CRCRLF nonsense line ending, correct them, check
them back in, and the game continues. Or files in .zip files get the
wrong line endings, etc. With Subversion, you can specify a CRLF line
ending for all text files so these things won't happen. I've used
Subversion for a while with DOSEMU and it works well.
I must say (from private mail) that Eric would rather stay with CVS
because of unfamiliarity with SVN and the fact that the working
directories take up twice the space (ie. 4MB instead of 2 for the
kernel for instance). The extra space comes from the caching of the
repository contents locally, which has its advantages too because an
"svn diff" or "svn revert" does not need to contact the server.
Another thing that may annoy some is that there exists no SVN client
for DOS. On the other hand, there exists no network aware CVS client
either... so I don't think anyone has ever checked out CVS sources
from SF on DOS. Thus this is more of a theoretical issue.
What do others think? I'd be happy to do the conversion myself.
Bart