DOS ain't dead

I use FreeDOS kernel 2039, JemmX and UIDE without /P parameter so far was everything fine and filesystem error occured only very rarely.
But yesterday I upgraded into new UIDE configured it with the /P option.

Then I wanted to so some work in FreePascal on old branch of Kasmar font editor.
But I even didn't run the compilation, only wanted to invoke Volkov commander from FP but it didn't work.
Then I leaved FP and some undeletable garbage occured in directory.
After quite big complications I more or less fixed it with Norton disk doctor 2002. Then I ran FP again and few times tried to compile it but very strange error messages occured.
Then I had to restart, ran again the NDD but damaged files and directories very everywhere on the disk and I lost much of data. I had to format the C: partition and restore my backups from flash drive and from notebook.

I don't want to experience it again so I would like to ask whether somebody knows what could be the problem.

I have to remark that it is no offense to Jack and his UIDE. I know that he always tests his software very detail so it is unlikely that it is the cause.

Anyway - do you have any suggestions?
Should I use another kernel?
Should I again run UIDE without /P ?
Something else?

---
DOS-u-akbar!

http://sf.net/tracker/?func=detail&aid=2901916&group_id=5109&atid=105109

> I use FreeDOS kernel 2039, JemmX and UIDE without /P parameter so far

Partition size, FAT subversion, free space ?

> damaged files and directories very everywhere on the disk and I lost much of data



> I don't want to experience it again so I would like to ask whether
> somebody knows what could be the problem.

Kernel 2039 ? I could reproduce BUG #2901916 without UIDE.

> Should I use another kernel?

2038.

BTW, I recently reproduced "the other" BUG #2380698 ( http://sf.net/tracker/?func=detail&aid=2380698&group_id=5109&atid=105109 ) with kernel 2038 and FAT16 (again 7-ZIP and big (ca 120 MiB) file)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> I use FreeDOS kernel 2039, JemmX and UIDE without /P parameter so far was
> everything fine and filesystem error occured only very rarely.
> But yesterday I upgraded into new UIDE configured it with the /P option.

IIRC you have available a Windows98 system, so can you try it with MS-DOS 7.10? Personally I had no problems with it using my MS-DOS 7.10 systems, so I rather believe it is a FreeDOS kernel issue. Anyway, I wouldn't recommend FreeDOS for serious tasks, at least never to my friends. IMO FreeDOS is still "only for testing purposes".

---
Glory to God for all things

> I have to remark that it is no offense to Jack and his UIDE. I know that
> he always tests his software very detail so it is unlikely that it is the
> cause. Anyway - do you have any suggestions? Should I use another
> kernel? Should I again run UIDE without /P? Something else?

"Be advised" these two things about UIDE. First, UIDE has absolutely NO
logic related to DOS directories or file structures. It reads or writes
data ONLY "to order" of the DOS system and then ONLY using a 24-bit "CHS"
address (V6.22 MS-DOS and older) or a 48-bit "LBA" address (V7.10 MS-DOS,
Win95/98, etc.). That is all UIDE gets from the system, when it gets an
"Int 13h" request to do disk I-O. Thus, if your directories or data get
corrupted, blame the "Commanding General" and not the poor-old "private",
and look at what disk orders the DOS system is "sending down" to UIDE!

Second, as I note in the README for my drivers, MS-DOS systems have a LOT
of ancient and uncorrected PROBLEMS in declaring "free" HMA space. With
V6.22 MS-DOS that I still have, it "declares" 26K of available HMA, but I
dare NOT take over 19K for UIDE's binary-search table, or the system will
CRASH sooner-or-later! V7.10 MS-DOS has a lot LESS -- It "declares" 13K
of available HMA, but UIDE dare not take over 9136 bytes, as I discovered
3 years ago!

I know FreeDOS is not MS-DOS, but if its HMA logic was based on that used
by MS-DOS, the same problems could exist!! Thus, you should try running
UIDE with /P (faster speed) but WITHOUT an /HL or /H switch (use no HMA).
This will require a bit more upper-memory, about 20K with a 500-MB cache.

However, if loading UIDE only in upper-memory (no /H nor /HL) avoids your
disk corruption, then FreeDOS must ALSO have problems in declaring "free"
HMA space! You then have two choices: Run UIDE with /P but without /HL
or /H and "tolerate" its using extra upper-memory; or run UIDE without /P
which takes a maximum 3840 bytes of HMA space and should not "bother" any
DOS system, even those with HMA-reporting errors! Not using /P will run
a bit slower, I know, but it may be necessary to solve your problems.

If NONE of these ideas about UIDE help, then "You know who to call!" i.e.
speak to the Volkov or FreeDOS people instead!

---
(Account disabled on user's request.)

Laaca didn't say anything about his use of UIDE with the "/H" or "/HL" switches. Certainly, MS-DOS 7.10 has problems, but FreeDOS has much more. I would strongly recommend you installing FreeDOS for testing purposes!

---
Glory to God for all things

> Laaca didn't say anything about his use of UIDE with the "/H" or "/HL"
> switches. Certainly, MS-DOS 7.10 has problems, but FreeDOS has much
> more. I would strongly recommend you installing FreeDOS for testing
> purposes!

I have tested FreeDOS from Lucho's 2008 "boot" diskette, which is much
simpler than putting the entire FreeDOS package on my hard-disk and so
LOSING my V6.22 MS-DOS. His "boot" diskette has only the 2035 kernel
but UIDE does run O.K. with it, even if loaded from AUTOEXEC (not from
CONFIG.SYS) using Eric Auer's "DEVLOAD" program. That allows UIDE to
load in the FreeDOS HMA, as they do not make HMA space available prior
to AUTOEXEC, i.e., not before the entire "system" and all .SYS drivers
have been loaded. No UIDE problems, even when loaded in FreeDOS HMA.

Today, Monday 24-May-2010, after originally writing this post, I chose
to (A) write one of Lucho's "boot" diskettes, (B) add to it the latest
XMGR/UIDE/UMBPCI/JEMM386 drivers and Auer's DEVLOAD, and (C) re-run my
file copy/compare test using my 74-MB of Windows system files. I ran
UIDE.SYS /S100 /P /H that sets a 100-MB cache, uses faster "protected
mode" cache methods (binary-search table in memory, not XMS), and sets
most of the driver logic in the FreeDOS HMA. Absolutely NO problems,
of any kind, with any of the newer drivers using the old 2035 kernel!

I have no experience re: newer FreeDOS kernels but I have read all the
problems with them. My opinion is that if UIDE works fine with 2035,
any issues using the newer 2036/2038/2039 kernels are most-likely "NOT
my problem"!

---
(Account disabled on user's request.)

Well, in the past I tried MS-DOS 7.1 but I had problem that it didn't properly handle deep directories - in MS-DOS 7.1 I wasn't able f.e. to delete directory structure of Windows 98 or the source tree of freepascal.
I had to switch into FreeDOS and delete it from it.

Now I am considering EDR-DOS, FreeDOS kernel 2038 and DatalightDOS.

---
DOS-u-akbar!

> Well, in the past I tried MS-DOS 7.1 but I had problem that it didn't
> properly handle deep directories - in MS-DOS 7.1 I wasn't able f.e. to
> delete directory structure of Windows 98 or the source tree of
> freepascal.

How deep directories?! Perhaps they didn't think at such deep directories, but what use have you of them in DOS? There is a lot of old DOS software perplexed by "deep directories". If you really need deep directories, use UNIX, not DOS.

---
Glory to God for all things

> Well, in the past I tried MS-DOS 7.1 but I had problem that it didn't
> properly handle deep directories - in MS-DOS 7.1 I wasn't able f.e. to
> delete directory structure of Windows 98 or the source tree of
> freepascal.
>
> I had to switch into FreeDOS and delete the directories from it.
>
> Now I am considering EDR-DOS, FreeDOS kernel 2038 and DatalightDOS.

If by "DatalightDOS" you mean ROM-DOS, my advice is to AVOID that system!
On a ROM-DOS system, if you use /HL or /H with UIDE, it posts a value for
"free" HMA but in fact has NONE, and this gives a system CRASH! ROM-DOS
has other problems, and I do NOT recommend it at all -- may work, but may
also FAIL, real BADLY!!

Also, I am told that sometime about-or-after Win98, "Gates & Co." updated
to what is known as "V8.0 MS-DOS", with additional features I cannot tell
you about since I do not use [and DETEST!] any "DOS form" of Windows. I
expect that "might" be why an older V7.1 MS-DOS system cannot handle your
"deep" directories -- only "V8.0 MS-DOS" may be able to do this!

Your best advice may be what "DOS386" says -- try the 2038 FreeDOS kernel
and "Bow to the Southeast!" [i.e. PRAY!!] before you do!!

---
(Account disabled on user's request.)

I hope you notice my irony. Stay with FreeDOS, disregarding WHO contributes.

---
Glory to God for all things

OK, installed FreeDOS, kernel 2038

---
DOS-u-akbar!

> OK, installed FreeDOS, kernel 2038

I did refer to posts like Eric Auer's.

---
Glory to God for all things

Said by Laaca :

>> Well, in the past I tried MS-DOS 7.1 but I had problem that it didn't
>> properly handle deep directories - in MS-DOS 7.1 I wasn't able f.e. to
>> delete directory structure of Windows 98 or the source tree of
>> freepascal.

MS-DOS can't handle path+filename longer than ~126 characters IIRC. It can still access them if you "navigate" down the structure. If you use only DOS there is little reason for creating deeply nested dirs (MS programs and Windows itself love to create long paths...)


>> I had to switch into FreeDOS and delete the directories from it.

But you could probably have done it from the MS DOS 7 command line too - possibly inconveniently

>> Now I am considering EDR-DOS, FreeDOS kernel 2038 and DatalightDOS.

(no meaningful advice here, skipping)

Now, Jack had this to say :

> Also, I am told that sometime about-or-after Win98, "Gates & Co." updated
> to what is known as "V8.0 MS-DOS", with additional features I cannot tell
> you about since I do not use [and DETEST!] any "DOS form" of Windows. I
> expect that "might" be why an older V7.1 MS-DOS system cannot handle your
> "deep" directories -- only "V8.0 MS-DOS" may be able to do this!

MS-DOS 8 (from WinME) is a crippled version, having features removed and no corrections that I know of. There is IMHO no functional reason whatsoever to use it rather than DOS 7.1 if given a choice; save for the smaller size of its IO.SYS, being compressed, which might be an advantage for cramming more files onto a DOS boot floppy (but DOS 7's IO.SYS can be compressed in a similar fashion if needed, cf. the Russian "LZDOS" which was mentionned on these forums several times. Or just removing the Windows start bitmap from DOS 7's IO.SYS even without compression does shrink it nicely...)

---
Ninho

Ninho said:
> MS-DOS can't handle path+filename longer than ~126 characters IIRC

67 characters is the documented path limit of MS/PC/DR/Free DOS.
Maybe one can go deeper by navigating the directory tree, but I don't
know whether it works in all versions.
If Laaca was able to use a longer absolute path in FreeDOS, this is
news.

Jassena said :
> 67 characters is the documented path limit of MS/PC/DR/Free DOS.

Apologies for my less than accurate recollection. I said ca. 126, thinking of the DOS command line buffer rather than the file API. My real point however was that there is a rather short limit to path lengths a user or programmer can pass directly to the DOS API.

With all the respect, not sure it's exactly 67 either ! The complete path+filename including slashes and dots and a terminal NUL should fit in a 80-byte long buffer, so if you want to be able to access a 8.3 filename in the directory of interest, the limit for the path seems to calculate out as 66 chars; on the other hand a one letter long filename without extension should be accessible within a 77 char long directory ! :=)

There might be differences whether using the old style FCB functions than new unixish file API. Disclaimer : I'm just chatting (again!), not checking my facts...

> Maybe one can go deeper by navigating the directory tree, but I don't
> know whether it works in all versions.

It works in MS-DOS. Of course excluding additional complications caused by e.g. invalid characters in directory/file names.

> If Laaca was able to use a longer absolute path in FreeDOS, this is
> news.


--
Ninho

> Anyway, I wouldn't recommend FreeDOS for serious tasks, at least never
> to my friends. IMO FreeDOS is still "only for testing purposes"

Strangely I don't see you reporting all the bugs you found into the TRACKER nor participating in bug tests and discussions

BTW, EDR-DOS doesn't have any of those 2 "critical-data-trashing-BUG's" either (it has many minor bugs, though: NTLFN-Find-First, NTLFN-Find-Next, and GetFileInfoByHandle still return garbage attributes, and NTLFN-Peek-Attributes ($7143) doesn't work at all ....).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I am silent now in this thread because it seems that problem was at least partialy caused by hardware problem - serious overheating.
And also I found that I don't load the latest version of UIDE but some version from year 2009.
So I can't reliably reproduce this problem.

---
DOS-u-akbar!

> Strangely I don't see you reporting all the bugs you found into the
> TRACKER
> nor participating in bug tests and discussions

I will never write on any FreeDOS board, tracker list etc. for two simple reasons: firstly because I am not interested in their main goals re: DOS, and secondly because their discussion style is totally repugnant to me.

---
Glory to God for all things

> Stay with FreeDOS, disregarding WHO contributes

http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02458.html
http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02462.html

Or just stay with M$:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***