From: <ait...@wa...> - 2004-03-30 08:48:23
|
>Of course! Neither do we call LBACACHE a SMARTDRV, don't we? >If we can live without a true SMARTDRV, we can live without a true >SCANDISK too. The case is not comparable either. I seem to recall (Alain was it you?) that it was mentioned copyright issues over the label "SMARTDRV", but I don't think there is any over "SCANDISK" (I may be wrong). Aitor |
From: Johnson L. <jo...@tm...> - 2004-03-30 11:47:48
|
On Tue, 30 Mar 2004 10:48:20 +0200, you wrote: Sorry for breaking in ... >The case is not comparable either. I seem to recall (Alain was it you?) that it was mentioned copyright issues over the label "SMARTDRV", but I don't think there is any over "SCANDISK" (I may be wrong). I'll think this way ... When FreeDOS kick off, the aim is to smoothly transfer the applications/games/utilities from dead M$-DOS to FreeDOS environment which most of the program are OpenSource. For the convenient of most users, we try to use the same name such as XCOPY or CHKDSK. But it's not a must! If there're sufficient reasons, program like LBACACHE or CDRCACHE is acceptable, but it must come together with a transition guide and documentation in order to let the old DOS user to switch to FreeDOS without much pain. If DOSFSCK can do the job similar or better than SCANDISK, then we don't need to insist on the name. For me, I think using the name DOSFSCK is better because it's NOT a direct replacement of SCANDISK. It's good that some nice guys here want to make a GUI for it, but the GUI may have a better name than SCANDISK. Rgds, Johnson. |
From: Bernd B. <bb...@ho...> - 2004-03-30 12:19:09
|
Johnson Lam schreef: > If DOSFSCK can do the job similar or better than SCANDISK, then we > don't need to insist on the name. For me, I think using the name > DOSFSCK is better because it's NOT a direct replacement of SCANDISK. > problem is DOSFSCK cannot do this yet. it is broken for at least FAT32. > It's good that some nice guys here want to make a GUI for it, but the > GUI may have a better name than SCANDISK. basically this means 3 programs: [1]*CHKDSK [2]*CHKDSK + GUI, call it SCANDISK (or whatever you prefer) [3]*DOSFSCK [1] requires 8086 but is limited to FAT16 [2] requires 8086, limited to FAT16, but can use external DOSFSCHK as engine if processor is 386+ simply a checkbox "use advanced checking engine if present" [3] requires 386 / DPMI for [2], I prefer it to not being only a GUI (and thus always requiring an external engine, be it CHKDSK or DOSFSCK) but include the CHKDSK engine by default. [3] is a standalone program, but can be called by SCANDISK to act as an engine for FAT32 checking. since [3] is DPMI (Protected Mode) it's not possible to combine both engines in a executable that still needs to run on 8086. that still keeps us with a problem: FAT32 drive on sub-386 systems. and another one: minimum amount of RAM for 386 is 1MB ? would that be enough for DOSFSCK? let's say at leat 2.5MB free RAM is required (typically on systems with at least 4MB total RAM) {1}if (cpu<386) OR (available extended_RAM< 2.5MB) AND Partition=FAT32 -> "sorry, we cannot scan a FAT32 partition on a system with a sub-386 processor or less than 2.5MB free RAM" {2}if (cpu<386) OR (available extended_RAM< 2.5MB) AND Partition=FAT16 -> "Sorry, DOSFSCK engine only available on systems 386+ processor and more than 2.5MB free" "using CHKDSK engine instead" {3}if (cpu>386) AND (available extended_RAM> 2.5MB) AND Partition=FAT32 -> "the DOSFSCK engine is required to scan this partition" but when DOSFSCK not found: "cannot continue checking FAT32 partition, required engine files DOSFSCK and CWSDPMI not found" {4}if (cpu>386) AND (available extended_RAM> 2.5MB) AND Partition=FAT16 -> "Using your preferred scanning engine: %scan_engine% but when DOSFSCK not found: "required external engine files DOSFSCK and CWSDPMI not found" "using internal CHKDSK engine instead" Bernd |
From: Johnson L. <jo...@tm...> - 2004-03-30 13:02:10
|
On Tue, 30 Mar 2004 14:20:49 +0200, you wrote: Hi, >problem is DOSFSCK cannot do this yet. it is broken for at least FAT32. CHKDSK also. >basically this means 3 programs: > >[1]*CHKDSK >[2]*CHKDSK + GUI, call it SCANDISK (or whatever you prefer) >[3]*DOSFSCK > >[1] requires 8086 but is limited to FAT16 >[2] requires 8086, limited to FAT16, but can use external DOSFSCHK as = engine if processor is 386+ > simply a checkbox "use advanced checking engine if present" >[3] requires 386 / DPMI > > for [2], I prefer it to not being only a GUI (and thus always = requiring an external engine, > be it CHKDSK or DOSFSCK) but include the CHKDSK engine by default. Should be easy to do, but since the main problem - FAT32, still not fully supported, only make a GUI+CHKDSK is not enough, and need extra time and effort to code. Imre is busy, and no one can pick up this job now. > [3] is a standalone program, but can be called by SCANDISK to act as = an engine for FAT32 checking. > > since [3] is DPMI (Protected Mode) it's not possible to combine both = engines in a executable > that still needs to run on 8086. If a single EXE of GUI need to do so many engine checking, why not improve the DOSFSCK? It'll take much longer time to code a GUI checking for different engines. >that still keeps us with a problem: FAT32 drive on sub-386 systems. >and another one: minimum amount of RAM for 386 is 1MB ? would that be = enough for DOSFSCK? Then we may need to fine-tune it by removing unnecessary code inside. Unlucky is I can't code, lucky is DOSFSCK is OpenSource. Maybe someone can help to improve it. >let's say at leat 2.5MB free RAM is required (typically on systems with = at least 4MB total RAM) > >{1}if (cpu<386) OR (available extended_RAM< 2.5MB) AND Partition=3DFAT32= -> >"sorry, we cannot scan a FAT32 partition on a system with a sub-386 = processor or less than 2.5MB=20 >free RAM" > >{2}if (cpu<386) OR (available extended_RAM< 2.5MB) AND Partition=3DFAT16= -> >"Sorry, DOSFSCK engine only available on systems 386+ processor and more= than 2.5MB free" >"using CHKDSK engine instead" > >{3}if (cpu>386) AND (available extended_RAM> 2.5MB) AND = Partition=3DFAT32 -> >"the DOSFSCK engine is required to scan this partition" > >but when DOSFSCK not found: >"cannot continue checking FAT32 partition, required engine files DOSFSCK= and CWSDPMI not found" > >{4}if (cpu>386) AND (available extended_RAM> 2.5MB) AND = Partition=3DFAT16 -> >"Using your preferred scanning engine: %scan_engine% > >but when DOSFSCK not found: >"required external engine files DOSFSCK and CWSDPMI not found" >"using internal CHKDSK engine instead" I can understand what you mean, but the problem is we don't have a direct replacement of CHKDSK/SCANDISK. This transition period I use both for myself but in future we need to consider a better way to do the job. During this period, we must have a better plan than temporary code a GUI for CHKDSK/DOSFSCK. The ideal program should work like CHKDSK/DOSFSCK ... maybe an EXE with or without GUI but it must support all FAT12, 16 and FAT32. Currently not much can do except someone will like to pick the job or wait for Imre. Rgds, Johnson. |
From: Bernd B. <bb...@ho...> - 2004-03-30 13:33:47
|
Johnson Lam schreef: > On Tue, 30 Mar 2004 14:20:49 +0200, you wrote: > > Hi, > > >>problem is DOSFSCK cannot do this yet. it is broken for at least FAT32. > > > CHKDSK also. > there does not exist a single CHKDSK/SCANDISK which can run on 16bit processors AND support FAT32. there does not exist a single CHKDSK/SCANDISK which runs under DOS system AND supports FAT32 the worry was that CHKDSK would run out of memory on scanning FAT32 partitions. (without DPMI you can only use conventional memory I think, and conventional RAM limited to 640KB). that's why there is no FAT32 support in any 16bit CHKDSK. and that's why Microsoft moved Fat32 scanning to the Windows application chkdsk.exe/scandskw.exe (and DOS version of SCANDISK was more advanced than DOS version of CHKDSK) so it seems like protected mode is required for FAT32 scanning. protected mode not available on sub-386 systems -> trouble and since chkdsk needs to run on 8086, it shall never handle FAT32 (since it first has to go in protected mode then). cpu filesystem free_RAM chosen engine example system --------------------------------------------------------------- <386 fat12/fat16 <2.5MB CHKDSK 8086/1MB <386 fat12/fat16 >2.5MB CHKDSK 80286/16MB <386 fat32 <2.5MB NONE 8086/1MB <386 fat32 >2.5MB NONE 80286/16MB 386+ fat12/fat16 <2.5MB CHKDSK 80386/2MB 386+ fat12/fat16 >2.5MB DOSFSCK/CHKDSK 80486/4MB 386+ fat32 <2.5MB NONE 80386/1MB 386+ fat32 >2.5MB DOSFSCK 80386/16MB Bernd |
From: Luchezar G. <lu...@ga...> - 2004-03-30 14:39:33
|
On Tue, 30 Mar 2004 14:20:49 +0200, Bernd Blaauw wrote: > problem is DOSFSCK cannot do this yet. it is broken for at least FAT32. Yes, DOSFSCK 2.10 (27.I.2004) works for small FAT32 volumes only. For example, it works for my 2000 MB FAT32 volume, but for my 25 GB FAT32 volume, it says: Checking whether we can access the last sector of the filesystem Seek to 26551170560:No error But I think this porting issue can more easily be fixed than implementing a full SCANDISK ;-) Lucho |
From: Bernd B. <bb...@ho...> - 2004-03-30 14:49:12
|
Luchezar Georgiev schreef: > Yes, DOSFSCK 2.10 (27.I.2004) works for small FAT32 volumes only. For > example, it works for my 2000 MB FAT32 volume, but for my 25 GB FAT32 > volume, it says: > > Checking whether we can access the last sector of the filesystem > Seek to 26551170560:No error > > But I think this porting issue can more easily be fixed than > implementing a full SCANDISK ;-) > yes, first working engines, then a GUI on top of it. but more stable than DOS + Win9x :) however I could not get DOSFSCK working at all last time I tried. that was when helping Eric testing FORMAT and FAT32 nice thing about VMware is that I can specify a 10GB virtual FAT32 volume, and the virtual harddisk won't take that size on my harddisk. Only what is actually filled. my largest harddisk is 70GB yet I can specify 256GB virtual disks :) don't think I tested with sub-2GB FAT32 partition size. Bernd |
From: Luchezar G. <lu...@ga...> - 2004-03-30 14:27:11
|
On Tue, 30 Mar 2004 10:48:20 +0200, Aitor wrote: >> If we can live without a true SMARTDRV, we can live without a true >> SCANDISK too. > > The case is not comparable either. I seem to recall (Alain was it you?) > that it was mentioned copyright issues over the label "SMARTDRV", but I > don't think there is any over "SCANDISK" (I may be wrong). If Microsoft have a a trademark called "SmartDrv", then why don't they sue IBM who offer it in their PC-DOS 7 and 2000? Or does the code license IBM have entitle them to use the trademark? By the way, the name "DOS" is a trademark of IBM, if I remember correctly (back in the 1960s). The functionality of LBACACHE is NOT that of SMARTDRV. Nor is the functionality of DOSFSCK that of SCANDISK. It's precisely their *functionality*, and not a trademark issue, that is the true reason why they're called LBACACHE and DOSFSCK, and not SMARTDRV and SCANDISK, respectively. Lucho |
From: Bernd B. <bb...@ho...> - 2004-03-31 19:55:50
|
Aitor, I really could use the keyboard layouts and the KEYB executable by now, for testing purposes. looks like KEYB cannot look into subdirectories, and thus the need for the PUSHD/POPD you see below: I'm not sure what KEYB does exactly for locating the layout file: 1)look in current directory? ( %_CWD% ) 2)look in directory where KEYB is located? 3)look in subdirectory KEY (if it exists) of any of the above mentioned directories? this because it's fast: step 4 is slow, and 5 also. 4)look in path? (%PATH%) 5)look in subdirectory KEY (if it exists) of any directory mentioned in the PATH? say path=c:\fdos say current directory is C:\ say C:\FDOS\BIN\KEY\BR274.KL and C:\FDOS\BIN\KEY\BR.KL exist say KEYB is called from autoexec.bat in the following way: C:\FDOS\BIN\KEYB br,,br274.kl /id:274 in above situation, 1) will fail 2) will fail 3) will fail 4) will fail 5) would succeed, as it finds the requested file in the subdirectory KEY of one of the directories mentioned in the PATH variable. can you help me out on this? I really do not wish to do the PUSHD/KEYB/POPD in autoexec.bat! Bernd :DoNLS if exist %fdosroot%\NLS\localize.%2 set lang=%2 set uniqueID=%3 rem Latin America has no codepage number; Japan has no CPI file if "%4"=="" goto loadkeyb if "%5"=="" goto loadkeyb if not exist %fdosroot%\bin\%5.CPI goto loadkeyb rem DEVLOAD DISPLAY.SYS CON=(%5,,1) %fdosroot%\bin\DISPLAY CON=(%5,,1) %fdosroot%\bin\MODE CON CP PREP=((%4) %fdosroot%\bin\%5.CPI) %fdosroot%\bin\MODE CON CP SEL=%4 pause goto loadkeyb :loadkeyb set keybfile=NoKeyboardLayout for %%x in ( %fdosroot%\bin\key\*.kl ) do if "%fdosroot%\bin\key\%6.kl"=="%%x" set keybfile=%%x for %%x in ( %fdosroot%\bin\key\*.KL ) do if "%fdosroot%\bin\key\%6.KL"=="%%x" set keybfile=%%x set keybline= if "%6"=="" goto end shift shift shift shift shift set keybline=%1 %2 %3 %4 %5 %6 %7 %8 %9 pushd %fdosroot%\bin\key for %%x in ( /U %keybline% ) do %fdosroot%\bin\keyb %%x popd pause goto end |
From: Bernd B. <bb...@ho...> - 2004-03-31 20:05:31
|
oops..turned into a public request. 2nd time this happens to me! anyway, I'm working on code to allow NLS settings in the next FreeDOS cdrom. (keyboard layouts, codepages) Bernd |