Re: [Freedos-devel] FORMAT 0.91r - new features / KERNEL DOS-1c & DOS-36 bugs

2004-07-18 Thread Arkady V.Belousov
Hi!

19-Июл-2004 02:25 [EMAIL PROTECTED] (Johnson Lam) wrote to
[EMAIL PROTECTED]:

>>So Aitor should now be happy with the features. I also noticed that atoi()
>>parses /f:1440k and /f:1440 and /f:1440unitscalledkilobytes all the same,
>>so for full MS syntax only /f:1.44... stuff is missing (so what?).
JL> I remember MS accept /f:1.44 but not a good pratice, should be /f:1440
JL> without "k"

 For this, instead dumb atoi() should be used strtoul().




---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] FORMAT 0.91r - new features / KERNEL DOS-1c & DOS-36 bugs

2004-07-18 Thread Johnson Lam
On Sun, 18 Jul 2004 06:49:58 +0200 (MEST), you wrote:

Hi Eric,

Your speed was so fast! I just finish formatting large hard disk with
0.91q and some different non-standard floppy size, just fine.

>So Aitor should now be happy with the features. I also noticed that atoi()
>parses /f:1440k and /f:1440 and /f:1440unitscalledkilobytes all the same,
>so for full MS syntax only /f:1.44... stuff is missing (so what?).

I remember MS accept /f:1.44 but not a good pratice, should be /f:1440
without "k"

Test again ...


Rgds,
Johnson.



---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] FORMAT 0.91r - new features / KERNEL DOS-1c & DOS-36 bugs

2004-07-18 Thread Aitor Santamaría Merino
Hi,
Eric Auer escribió:
[...]
So Aitor should now be happy with the features.
Okay, I have updated the todo list entry for FORMAT to "fix bugs" 
(please note: web server not yet updated). Actually, Eric, you can close 
1022 (as I assume that this feature is supported), and maybe some 
FreeDOS users or developers with partitions/drives bigger than 4GB, so 
that you can also close 998 and FORMAT becomes "Ready!".
Anyway notice that, except for the missing SCANDISK, at least all the 
disk utilities are at most set to "fix bugs" (no features remaining), 
same goes for file utilities and user interface utilities.
I finish just by mentioning those utilities that numerically, the 
utilities that show numerically more features to do are PRINT and MEM 
(presently not being worked on, I think), and besides my own utilities 
that I hope to work out this summer.
And those having larger amount of bugs remaining are Kernel, FreeCOM, 
FDISK and INSTALL.

Happy coding and debugging!
Aitor
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


[Freedos-devel] FORMAT 0.91r - new features / KERNEL DOS-1c & DOS-36 bugs

2004-07-17 Thread Eric Auer

Hi, I have updated (5+ hours) FORMAT to version 0.91r:

http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ format-0.91r.zip

Version 0.91r (18 Jul 2004) 
  Changes by Eric Auer: 
  - unless you use the /D option, we now use boring MS compat 
errorlevels: 0 ok, 3 user abort, 4 fatal, 5 not confirmed 
(WITH /D option: see help.txt for new errorlevels...!) 
  - attempt to lock non-existing drives is recognized as such 
(in FAT16 DOS, attempt to get parameters of non-existing
drive, *after* format confirmation, is recognized... This
is a kludge as FreeDOS 2035 int 21.36/21.1c return wrong
errors for unformatted *existing* drives. Happy fixing!?) 
  - now unlocking drives in case of an abort (not for ^C yet)
  - prompts for label if no /V:... given, unless /Y used
  - Mirror aborts if it would overwrite used data, SafeFormat
gives a warning if mirror data damaged unformateable data
  - shortended debug messages even more (e.g. in createfs)

So Aitor should now be happy with the features. I also noticed that atoi()
parses /f:1440k and /f:1440 and /f:1440unitscalledkilobytes all the same,
so for full MS syntax only /f:1.44... stuff is missing (so what?).

Summary of the highlights:
- MS compatible errorlevels in normal mode
- more informative errorlevels in /D mode
- unlocks drive if an error happens
- prompts for a volume label (if none given at command line and if not in /y
  noninteractive mode). For sequential floppy mode, FORMAT always asks for
  labels for subsequent disks.
- MIRROR refuses to damage the contents of used clusters. Only SafeFormat is
  allowed to damage data in order to make UnFormat possible in any case.

The binary size is still slightly below 32768 bytes ;-)).

Happy testing!

When trying to make FORMAT properly distinguish between
- SafeFormatable drives
- not yet formatted drives and
- non-existing drives
I found that FreeDOS kernel is really buggy in several aspects here.
The FAT32 version of the kernel is best: LOCK will fail for non-existing
drives. For existing drives, I can distinguish between formatted and not
yet formatted drives by reading the boot sector.
The FAT16 version compatible calls are worse: int 21.440d.0860 is okay
for detecting non-existing drives, BUT I have to wait with this call
until AFTER the "do you really want to..." confirmation and LOCK call.

It would be better if int 21.36 and int 21.1c would work properly. But:
When I call int 21.36 for a not yet formatted drive (it properly detects
non-existing drives, at least), I trigger an INTERACTIVE critical error.
This confuses people, so I cannot use it in FORMAT. All four choices,
abort, ignore, retry, fail, work, but of course RETRY will be infinite
and IGNORE is dangerous here, so the whole interactivity is a BUG in our
kernel. Correct reaction would be to return error 7, unknown media type
(in terms of critical error, that is category "fail"). For non-existing
drives, a special (non-error) return value is already defined and working.

Things got even worse when I tried int 21.1c as an alternative: This is
less recommended because Win9x reportedly has bugs in this function (it
might help to check sector size as extra test). For non-existing drives,
the correct non-error special return value is returned, but for not yet
formatted drives, the whole kernel CRASHES!

DS = 0xcf ES=SS = from caller CS = wrong
SP = 0xc33d AX = 0x3504 BX = 0x574 CX = 0x6FE DX = 4 SI = 0x574 DI = 0x0E BP = 0x70
... but that probably does not help much because CS already went mad.

Even happens in 2035a:
debug
w somenonsense 4 0 1 (zap boot sector of E:, don't try at home)
q
reboot
debug
acs:100
mov ah,1c
mov dl,5
int 21
nop
int 20
gcs:106 (drive is 1-based in int 21.1c, so we again check E:)
--> DOSEmu tells:

AX=3804  BX=1a92  CX=  DX=00d2  SI=0586  DI=000c  SP=ffe0  BP=0070
DS=00d2  ES=0889  FS=  GS=  FL=0246
CS:IP=:0002   SS:SP=0889:ffe0
:0002 6303 arpl[bp+di],ax

SP was FFFE and segments were 889 when I did "gcs:106", so:
DS points to kernel, AH is "something", AL pretends that the disk would
actually be formatted, BX pretends that the whole disk would be free,
CX is either not set yet or tells "sector size 0", DX is the kernel segment,
SI is "something", DI is "something" (maybe we are in a messed up critical
error state "general failure" here?), BP is yet another kernel segment. Stack:

0889:ffe0 07 03 FF FF 46 00 00 1C 00 00 00 00 05 00 00 00  ..F...
0889:fff0 00 00 00 00 89 08 89 08 06 01 89 08 02 02 00 00  

And yes, looks INTish:

...
:02f3 FE062003 inc byte ptr [0320]
:02f7 FE0E2103 dec byte ptr [0321]
:02fb 268E163000   mov ss,es:[0030]
:0300 268B262E00   mov sp,es:[002e]
:0305 CD24 int 0x24