Re: [Freedos-user] features of FreeDOS vs. MS/PC-DOS: roadmap ideas

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

19--2004 03:12 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:

EA is at best simplistic (okay, ClamAV ClamScan is not ;-)),
EA our HIMEM does not load parts of itself to HMA,

 FD-HIMEM under FreeDOS uses 2.03k of low memory, MS-HIMEM - 47.8k. Ant
this is not much more, than 1.14k of MS-HIMEM under MS-DOS.

EA make HIMEM load part of itself to HMA (by the way, EMM386 could conceivably
EA move itself to UMB...),

 FD-EMM386 uses 2.54k of low memory. MS-EMM386 uses 3.04k of low memory
plus 5.15k (14Ah para) hidden from UMB.




---
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_idG21alloc_id040op=click
___
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] features of FreeDOS vs. MS/PC-DOS: roadmap ideas

2004-07-19 Thread Johnson Lam
On Mon, 19 Jul 2004 12:35:06 +0200, you wrote:

Hi,

I think we can postpone SCANDISK to post-1.0, for example PC-DOS
does not have one either.
  
Everybody agrees?

Scandisk can be later, but the CHKDSK or DOSFSCK still have FAT32
problem. IMO at least one program should work correctly.


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=4721alloc_id=10040op=click
___
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] features of FreeDOS vs. MS/PC-DOS: roadmap ideas

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

19--2004 14:05 [EMAIL PROTECTED] (Bernd Blaauw) wrote to
[EMAIL PROTECTED]:

 FD-HIMEM under FreeDOS uses 2.03k of low memory, MS-HIMEM - 47.8k. Ant
this is not much more, than 1.14k of MS-HIMEM under MS-DOS.
BB as told, the 47.8KB usage is a bug in MS's kernel (IO.SYS , dos 7.10,
BB Win95OSR2..Win98SE),

 I mean FreeDOS kernel.

BB Arkady, do you still need compiling instructions for FreeCOM?

 Why? Instead downloading and compiling all FreeCOM sources me enough
one already compiled executable. Especially because I don't plan to
intervene into FreeCOM development process.




---
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_idG21alloc_id040op=click
___
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] features of FreeDOS vs. MS/PC-DOS: roadmap ideas

2004-07-18 Thread Eric Auer

Hi!

I have closed:
http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1022
and updated:
http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=998

I think we can postpone SCANDISK to post-1.0, for example PC-DOS
does not have one either.


http://www-306.ibm.com/software/os/dos/psm952a.html
tells us about PC-DOS vs MS-DOS: PC-DOS has no QBASIC/SCANDISK,
but it has: PCMCIA, nice installer, calculator, nice editor, REXX language,
DYNALOAD, task scheduler, APM 1.1 support, nice file transfer and sync user
interface, full version of UNDELETE including user interface and resident
helpers, improved help viewer, better virus detection (including heuristics
and description database), full backup suite with nice user interface and
tape/CD support, high end compressed file system (small, strong and compat.
with doublespace/drivespace: it is Stacker 4.0), reduced memory footprint.
Some things where both MS- and PC-DOS are better than FreeDOS:


- they have compressed read/write filesystem support
- they have some kind of backup tool
- they have a good undelete tool
- they include some laplink-like software
- they include some fancy scripting language (Basic, REXX)
Smaller differences: Our text editor is buggy, our virus protection
is at best simplistic (okay, ClamAV ClamScan is not ;-)), our HIMEM
does not load parts of itself to HMA, our DISPLAY has some huge memory
footprint, our SHARE is big as well, we have no delayed-write cache,
we have no NLSFUNC yet, our SETVER abilities are quite limited, our
CD-ROM lowlevel driver is bad (does PC-DOS include a generic one?),
we have no DOSSHELL.

Things which we could improve: ATAPICDD, *maybe* do something with that
PCMCIA code fragment, improve the installer and make a spin-off SELECT
utility, test some of the available task switchers / GUIs, include a
CALCULATOR, include a SCHEDULER, include BASH (scripting language!),
improve DEFRAG (FAT32 support, speed), include some file transfer tools
(SSHDOS SCP2DOS requires a SSH server, otherwise useful ;-)),
improve UNDELETE (- delete tracker / trashcan TSRs, FAT32), fix EDIT
and readonly mode of it, add NLSFUNC, add delayed-write feature to
cache, shrink and improve SHARE (PCDOS: 3k, MSDOS: 6k, FreeDOS: 10k for
my version), shrink DISPLAY (PCDOS: 5k , MSDOS: 8k, FreeDOS: 21k!),
make HIMEM load part of itself to HMA (by the way, EMM386 could conceivably
move itself to UMB...), add at (e.g. readonly) compressed filesystem driver.

Our memory footprint for kernel (including DOSDATA=UMB :-)), EMM386, shell,
NANSI, history, ramdisk and cache is already as good as the MS/PC-DOS one,
in some aspects even better. Great news :-).



From the bug list: FDISK disk detection, DIR for big disks, installer
flaws, disk error processing, occasional incompatibilities and some
really high profile compatibility problems (NetWare, Win3.x) ...

From the TODO list: [Wildcard REN *is* implemented, it seems???]
shell int 2e support, ATAPICDD stuff, print queue things, NLSFUNC,
more MEM features.

From the post 1.0 TODO list: FAT type conversion tool, BACKUP tool,
compressed filesystem, taskswitcher/filemanager, non-standard (floppy?)
disk support, FASTOPEN(?), remote drive letter/file transfer driver/tool,
config helper for RAM usage optimization, localized-bootdisk creator,
MSish menu language, SETVER, fancy EMM386 and HIMEM features, support for
sector sizes other than 512 bytes, full FAT32 support, delayed-write cache,
fancy cache features, fancy and TSR features for UNDELETE.

Widespread problems: Many tools have no string translation support yet,
nothing (not even the kernel - I think kernel and XCOPY would be enough?)
supports files above 2 GB size yet, many tools use no NLS/COUNTRY for number
displays.

Less widespread problem: Some tools (which?) use no NLS/COUNTRY for display
of date/time and for upcasing/sorting yet. Kernel has a bug in 1.68 MB
support (access works, but only *after* reading config sys...). At least
CHKDSK / DEFRAG but possibly also MIRROR / UNFORMAT / SYS / DISKCOMP /
DISKCOPY have no 1.68 MB support yet. MIRROR, UNFORMAT, DISKCOMP, DISKCOPY,
DEFRAG, CHKDSK and UNDELETE have no FAT32 support yet (please tell if I did
forget to mention some other tool with missing support!). Maybe diskcomp and
diskcopy are lacking FAT16 support, and maybe mirror and unformat are missing
FAT12 support?? Are there any tools which do not at least support 360k, 720k,
1220k and 1440k floppy formats??

Hope you enjoyed this summary and outlook :-)).

PS: Shrinking DISPLAY to half size should be easy (it now has 2 buffers
for each font size I think), just let the 2nd buffer reside e.g. in XMS.
To reach even lower sizes you would have to drop the ability to give
the user eternally valid pointers for all font sizes (in other words,
I suspect that PC-DOS DISPLAY only gives a pointer for ONE font size, and
if you ask it for a pointer to another font size, the first pointer will
be invalid). If you think that 10k are still too much, a solution would