You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(280) |
Feb
(411) |
Mar
(455) |
Apr
(367) |
May
(125) |
Jun
(155) |
Jul
(266) |
Aug
(131) |
Sep
(223) |
Oct
(76) |
Nov
(103) |
Dec
(132) |
2005 |
Jan
(70) |
Feb
(113) |
Mar
(57) |
Apr
(38) |
May
(110) |
Jun
(74) |
Jul
(365) |
Aug
(198) |
Sep
(116) |
Oct
(119) |
Nov
(184) |
Dec
(55) |
2006 |
Jan
(97) |
Feb
(70) |
Mar
(51) |
Apr
(16) |
May
(46) |
Jun
(176) |
Jul
(305) |
Aug
(427) |
Sep
(223) |
Oct
(121) |
Nov
(112) |
Dec
(48) |
2007 |
Jan
(16) |
Feb
(19) |
Mar
(67) |
Apr
(69) |
May
(48) |
Jun
(35) |
Jul
(26) |
Aug
(44) |
Sep
(33) |
Oct
(86) |
Nov
(15) |
Dec
(28) |
2008 |
Jan
(120) |
Feb
(7) |
Mar
(76) |
Apr
(47) |
May
(41) |
Jun
(24) |
Jul
(25) |
Aug
(34) |
Sep
(58) |
Oct
(7) |
Nov
(16) |
Dec
(40) |
2009 |
Jan
(17) |
Feb
(53) |
Mar
(121) |
Apr
(69) |
May
(28) |
Jun
(39) |
Jul
(12) |
Aug
(22) |
Sep
(25) |
Oct
(15) |
Nov
(53) |
Dec
(9) |
2010 |
Jan
(10) |
Feb
(30) |
Mar
(10) |
Apr
(44) |
May
(36) |
Jun
(14) |
Jul
(21) |
Aug
(19) |
Sep
(1) |
Oct
(6) |
Nov
(22) |
Dec
(11) |
2011 |
Jan
(10) |
Feb
(45) |
Mar
(6) |
Apr
(7) |
May
(38) |
Jun
(40) |
Jul
(248) |
Aug
(150) |
Sep
(124) |
Oct
(40) |
Nov
(36) |
Dec
(57) |
2012 |
Jan
(64) |
Feb
(22) |
Mar
(14) |
Apr
(20) |
May
(54) |
Jun
(27) |
Jul
(36) |
Aug
(63) |
Sep
(11) |
Oct
(4) |
Nov
(13) |
Dec
(33) |
2013 |
Jan
(49) |
Feb
(36) |
Mar
(8) |
Apr
(17) |
May
(34) |
Jun
(24) |
Jul
(45) |
Aug
(4) |
Sep
(14) |
Oct
(8) |
Nov
(3) |
Dec
(16) |
2014 |
Jan
(32) |
Feb
(10) |
Mar
(41) |
Apr
(35) |
May
(23) |
Jun
(9) |
Jul
(110) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(16) |
Dec
(77) |
2015 |
Jan
(249) |
Feb
(9) |
Mar
(95) |
Apr
(28) |
May
(126) |
Jun
(151) |
Jul
(11) |
Aug
(35) |
Sep
(258) |
Oct
(198) |
Nov
(123) |
Dec
(186) |
2016 |
Jan
(166) |
Feb
(100) |
Mar
(11) |
Apr
(4) |
May
(24) |
Jun
(13) |
Jul
(34) |
Aug
(18) |
Sep
(8) |
Oct
(49) |
Nov
(69) |
Dec
(33) |
2017 |
Jan
(20) |
Feb
(29) |
Mar
(2) |
Apr
(4) |
May
(33) |
Jun
(32) |
Jul
(16) |
Aug
(8) |
Sep
|
Oct
(67) |
Nov
(39) |
Dec
(4) |
2018 |
Jan
(29) |
Feb
(42) |
Mar
(2) |
Apr
(5) |
May
(13) |
Jun
(24) |
Jul
(160) |
Aug
(76) |
Sep
(64) |
Oct
(42) |
Nov
(47) |
Dec
(32) |
2019 |
Jan
(33) |
Feb
(29) |
Mar
(36) |
Apr
(11) |
May
(11) |
Jun
(18) |
Jul
(20) |
Aug
(11) |
Sep
(7) |
Oct
(16) |
Nov
(3) |
Dec
(20) |
2020 |
Jan
(10) |
Feb
|
Mar
(10) |
Apr
(13) |
May
(53) |
Jun
(26) |
Jul
(8) |
Aug
(20) |
Sep
(8) |
Oct
(60) |
Nov
(93) |
Dec
(119) |
2021 |
Jan
(20) |
Feb
(54) |
Mar
(26) |
Apr
(17) |
May
(200) |
Jun
(231) |
Jul
(124) |
Aug
(100) |
Sep
(25) |
Oct
(18) |
Nov
(17) |
Dec
(93) |
2022 |
Jan
(129) |
Feb
(59) |
Mar
(58) |
Apr
(70) |
May
(39) |
Jun
(22) |
Jul
(83) |
Aug
(110) |
Sep
(65) |
Oct
(80) |
Nov
(42) |
Dec
(19) |
2023 |
Jan
(145) |
Feb
(118) |
Mar
(179) |
Apr
(76) |
May
(46) |
Jun
(67) |
Jul
(76) |
Aug
(69) |
Sep
(31) |
Oct
(52) |
Nov
(82) |
Dec
(46) |
2024 |
Jan
(51) |
Feb
(97) |
Mar
(50) |
Apr
(51) |
May
(150) |
Jun
(96) |
Jul
(117) |
Aug
(87) |
Sep
(105) |
Oct
|
Nov
|
Dec
|
From: Patrick J. L. <pa...@us...> - 2004-01-20 16:46:18
|
Luchezar Georgiev <lu...@ga...> writes: > > (Although the "UMB" does not seem to do anything; the kernel says > > "No UMB's available!" every time. Is this normal?) > > Yes, this is normal, because you REQUEST using UMBs (DOS=..., > DEVICEHIGH=...) but you DON'T have an UMB "provider" like UMBPCI or > EMM386 installed! Shows how ignorant I am about DOS memory management. :-) > Yes, FDXMS can't detect which A20 switching method to use and this > is a disadvantage against HIMEM That is a pretty huge disadvantage... Dare I ask why FreeDOS has both? > The compressed HIMEM64 binary "as is" doesn't work in DR-DOS since > its decompression stub has some incompatibility with their kernel, > but works with all other DOS kernels I tested, including > FreeDOS. But as the symptom is just like it was on DR-DOS, it seems > the problem is the same for you. So enclosed is a binary HIMEM64.EXE > file I compiled myself, UNCOMPRESSED. May it run for you! It works flawlessly. Thank you!! By the way, I should probably mention that I am booting a FreeDOS "virtual floppy" over the network using PXELINUX and memdisk. (Network boot is the only way to install a system, in my opinion.) Perhaps this is related to the decompression problem; I did not even try using a physical floppy. Let me know if you want me to try that, or anything else I can do to help you debug. Thanks again! - Pat |
From: Luchezar G. <lu...@ga...> - 2004-01-20 16:11:46
|
On Tue, 20 Jan 2004 10:39:51 -0600, Steve Nickolas wrote: >>> FreeDOS SCANDISK hangs on everything - by design. >>> The only bug is that it's distributed at all. >> >> But ... why still including it in the distribution package without any >> warning message? > > Good question. --; Indeed! But who is its maintainer and if there is still one (albeit maybe only formally), does he have anything to say? Lucho |
From: Luchezar G. <lu...@ga...> - 2004-01-20 16:02:41
|
On 20 Jan 2004 08:52:03 -0500, Patrick J. LoPresti wrote: > I finally got around to testing this, and I can confirm that it almost works. > Installing Windows itself does work. I can run winnt.exe (16-bit Windows Setup) using these FreeDOS binaries to install Windows. Nice job, everyone! We (Bart, the other kernel developers and I) thank you very much for this compliment of yours! ;-) > But I cannot quite use FreeDOS for my project, yet. Something strange is happening with keyboard input under fdxms. Because you need PS/2 type switching of A20, but FDXMS does AT by default which uses the keyboard controller to switch A20! > My config.sys is very simple: > > LASTDRIVE=Z > DOS=HIGH,UMB > DEVICE=FDXMS.SYS > DEVICEHIGH=\NET\IFSHLP.SYS > FILES=30 > > (Although the "UMB" does not seem to do anything; the kernel says "No UMB's available!" every time. Is this normal?) Yes, this is normal, because you REQUEST using UMBs (DOS=..., DEVICEHIGH=...) but you DON'T have an UMB "provider" like UMBPCI or EMM386 installed! > The trouble starts whenever the system stops to prompt for input. It is a little random, but sooner or later it locks up completely on some prompt or other. > > This only happens on one of the two systems I have been testing (IBM Thinkpad T20 laptop), but not on the other (Dell Dimension GX200 desktop). > > I finally discovered that I can work around the problem like this: > > DEVICE=FDXMS.SYS PS2 Yes, FDXMS can't detect which A20 switching method to use and this is a disadvantage against HIMEM > (I also tried using HIMEM.EXE from the EMM386 package, but that just gets an illegal instruction crash immediately.) The compressed HIMEM64 binary "as is" doesn't work in DR-DOS since its decompression stub has some incompatibility with their kernel, but works with all other DOS kernels I tested, including FreeDOS. But as the symptom is just like it was on DR-DOS, it seems the problem is the same for you. So enclosed is a binary HIMEM64.EXE file I compiled myself, UNCOMPRESSED. May it run for you! > I am not sure what to make of this. MS-DOS with himem.sys did not require any special switches (except maybe /testmem:off), and it works on every system I have ever encountered. Is the "PS2" switch safe to use in general? What switches should I provide to fdxms if I want the best chance of working on the widest variety of hardware? If you provide PS2 but the system uses the old (AT) method, you're out of luck! Better use HIMEM64 (enclosed) which (unlike FDXMS) doesn't need a "machine" switch and detects the A20 method itself! Lucho P.S. I believe that SourceForge will pass my attachment untouched to the mailboxes of the subscribers of the mailing list but the mail archive will probably lack it - sorry, can't help :-( P.P.S. Just tried sending the EXE file directly and got it bounced back! Now let's try with a ZIP! |
From: tom e. <te...@dr...> - 2004-01-20 15:47:09
|
>>FreeDOS SCANDISK hangs on everything - by design. >>The only bug is that it's distributed at all. JL> But ... why still including it in the distribution package without any JL> warning message? good question - unanswered for > 2 years :((( raises a bug report once per month and serves no other purpose. probably only possible answer: open source projects like to have as much software available as possible (even if it's complete junk) tom |
From: Steve N. <uso...@ve...> - 2004-01-20 15:40:23
|
Johnson Lam wrote: > On Tue, 20 Jan 2004 09:14:49 +0100, you wrote: > > Hi > >>FreeDOS SCANDISK hangs on everything - by design. >>The only bug is that it's distributed at all. > > But ... why still including it in the distribution package without any > warning message? Good question. --; -uso. |
From: Johnson L. <jo...@tm...> - 2004-01-20 15:07:27
|
On Tue, 20 Jan 2004 09:14:49 +0100, you wrote: Hi >FreeDOS SCANDISK hangs on everything - by design. >The only bug is that it's distributed at all. But ... why still including it in the distribution package without any warning message? Rgds, Johnson. -------------------------------------------------------- Hong Kong - International Joke Center (after 1997-06-30) |
From: Luchezar G. <lu...@ga...> - 2004-01-20 14:52:20
|
On Tue, 20 Jan 2004 04:34:37 +0100 (MET), Eric Auer wrote: > Hi, Konstantin of DeskWork.de likes to announce his new stripped-down > ANSI clone which is only 2k in RAM and on DISK (NANSI is about 3k, a > bit more if you do not block key redefinitions with the /S flag). > [...] http://www.deskwork.de:80/HOME/STUFF/ANSI.ZIP Thanks - nice try, twice as less resident RAM usage (1.7K vs 3.3K) but has problems even on my relatively new machine. First, screen text is BLUE instead of WHITE, second, 4DOS keys don't work, third, ELVIS for DOS keys don't work and screen is messed up... Sorry, but can't replace NANSI :-( Lucho |
From: Patrick J. L. <pa...@us...> - 2004-01-20 13:52:05
|
The story so far: I want to use FreeDOS for my project's boot disk (http://unattended.sourceforge.net/). I reported problems with running winnt.exe under FreeDOS a while ago: http://www.mail-archive.com/fd-...@to.../#00026 Eventually, Thomas Hirsh and Bernd Blaauw suggested trying the current development version: http://www.freedos.org/freedos/news/technote/206.html http://www.zytor.com/pipermail/syslinux/2003-December/002915.html ... Bernd, I apologize for the long delay in replying. "Blaauw,Bernd B." <B.B...@st...> writes: > Patrick, please see > http://www.fdos.org/ripcord/beta9rc4/bugsolve/bootdisk.img > > and test if you can use FreeDOS kernel by now for your unattended > project. I finally got around to testing this, and I can confirm that it almost works. Installing Windows itself does work. I can run winnt.exe (16-bit Windows Setup) using these FreeDOS binaries to install Windows. Nice job, everyone! But I cannot quite use FreeDOS for my project, yet. Something strange is happening with keyboard input under fdxms. My config.sys is very simple: LASTDRIVE=Z DOS=HIGH,UMB DEVICE=FDXMS.SYS DEVICEHIGH=\NET\IFSHLP.SYS FILES=30 (Although the "UMB" does not seem to do anything; the kernel says "No UMB's available!" every time. Is this normal?) My autoexec.bat is more complicated. You can find it at: http://cvs.sourceforge.net/viewcvs.py/unattended/unattended/bootdisk/template/autoexec.bat?view=auto All it wants to do is map a network share to the Z: drive and invoke a Perl script (using DJGPP). The Perl script does all the hard work of asking questions and generating unattend.txt. The trouble starts whenever the system stops to prompt for input. It is a little random, but sooner or later it locks up completely on some prompt or other. This only happens on one of the two systems I have been testing (IBM Thinkpad T20 laptop), but not on the other (Dell Dimension GX200 desktop). I finally discovered that I can work around the problem like this: DEVICE=FDXMS.SYS PS2 (I also tried using HIMEM.EXE from the EMM386 package, but that just gets an illegal instruction crash immediately.) I am not sure what to make of this. MS-DOS with himem.sys did not require any special switches (except maybe /testmem:off), and it works on every system I have ever encountered. Is the "PS2" switch safe to use in general? What switches should I provide to fdxms if I want the best chance of working on the widest variety of hardware? Thanks! - Pat P.S. I am still using MS smartdrv (http://support.microsoft.com/?id=296814). I will give lbacache a try later today. |
From: Arkady V.B. <ar...@be...> - 2004-01-20 13:46:54
|
Hi! 20-=F1=CE=D7-2004 04:34 _eric@CoLi.Uni-SB.DE (Eric Auer) wrote to fre...@li...: EA> 102 key keyboards and VGA compatible graphics, AUTOMATICALLY detects EA> which modes are text modes (queries the CRT Controller "text mode" bi= t), You mean bit 0 of GC6 (Graphics Controller miscellanous graphics control), which disbles character generator? This is best way to differ t= ext and graphics mode, but it works only on VGA - on EGA most registers are write-only, on CGA there is no such register. |
From: tom e. <te...@dr...> - 2004-01-20 08:29:24
|
JT> Hi! JT> I just used scandisk with kernel 2032a, fat16, and comxswp.com. JT> It hangs after the media check. Anyone have any ideas why? FreeDOS SCANDISK hangs on everything - by design. The only bug is that it's distributed at all. tom |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-20 07:47:48
|
Hi, some Windows compatibility results: Windows 2000 pretents to be DOS 5.0 (!) so FORMAT fails to notice that it should do drive locking. If you run FORMAT through CALLVER in FREECOM, it tries to LOCK the drive but the request gets rejected (error 1). You can ONLY format floppy disks with FreeDOS FORMAT in Windows 2000 and probably only if you manually did the locking. Note that CALLVER 7.10 FORMAT does not work with the default CMD shell, because CMD will refuse to run under DOS 7.10 ... weird MS world! In the DOS of Windows 98 SE, the values for "FileSystem Info Sector" and "Backup Boot Sector" postition are both 0 (FORMAT rejects them as invalid) although RBIL IntList 61 tells that "none" should be represented by 0xffff! To make things even worse, Get_FS_Info detects FAT16 but clusters are > 65525L on an 8 GB partition, so FORMAT realizes pretty late that the drive is FAT32. ... I have used the collected feedback to add extra sanity checks and to make the error messages a bit nicer. You can get the new incarnation of format-0.91l.zip ("l" like in "lame") at http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ ... as usual. Really good question is what causes "sector 0 contains FS info sector instead of boot sector after FORMAT under Win98se sometimes". There are really enough sanity checks that should help to avoid that by now!?!? A new logfile suggests that FreeDOS format is undecided between FAT16 and FAT32 because access type is FAT32 but FAT1x size is nonzero! Probably because a strange format has been created for it before. The new upload is now VERY crowded with sanity checks, and when in doubt, it enforces a proper FAT32 or FAT1x format rather than a "double" one. All this would be easier if DEBUG could be used as FAT32 sector editor already ;-). At least I tested with random data overwriting FAT1x boot sectors, and FORMAT "survived" both for FAT12 and FAT16, did not save unformat data (because of the implausibility of the random boot sector) and was even able to UNFORMAT the drive after that (using an older version of the unformat data - as told, it did not overwrite the existing unformat data with the data of the filesystem with the random/broken boot sector). As usual: No matter how foolproof it is, there will always be something out there which will break it because it is even more foolish. I hope and think that that Win98SE thing is not Win98SE typical but is an unfortunate property of FORMAT related to preserving broken FAT32 states. Probably zapping the boot sector (e.g. with some FDISK maybe? Or of course with dd if=/dev/zero bs=512 count=1 conv=notrunc of=/dev/victim ... but never type the wrong victim for that!) would resolve the issue. We will find out. Maybe you can test FAT32 formatting under Win9x DOS mode and/or Win9x DOS box and check whether the created filesystems are okay. If not, please use the /d (verbose debug messages) mode and store a log file: format x: /v:fat32test /d >logform.txt Do not quote the whole file, just the lines (beginning) ... (beginning of mirror map writing or alternatively the error message which tells why the mirror map is not written) and if mirroring is used, the lines which tell which the last FAT sector is and which root dir sectors are mirrored (if none, tell about that) and "Creating File System" ... "Clearing FAT Sectors" (without the sector list!) and "Writing FAT1 Headers" ... "Clearing Root Directory" (without the sector list!) and the final statistics (after "Format complete") If I say "without the sector list", I mean "do not quote that "99, 100, 101..." kind of text, but do quote things like "Sectors 99 to 999" or "Sector -> 9". Thanks for your help with debugging... Eric. PS: I would be happy to hear that FORMAT 0.91L *does* create proper FAT32 filesystems in FreeDOS and maybe even Win9x in general. If the abovementioned Win98SE bug happens all the time, it would really give me a bad time :-/. |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-20 03:34:42
|
Hi, Konstantin of DeskWork.de likes to announce his new stripped-down ANSI clone which is only 2k in RAM and on DISK (NANSI is about 3k, a bit more if you do not block key redefinitions with the /S flag). Features: NO command line switches, NO documentation, ONLY supports 102 key keyboards and VGA compatible graphics, AUTOMATICALLY detects which modes are text modes (queries the CRT Controller "text mode" bit), uses the BIOS for non-text modes and always for the bell/beep, does NOT support keyboard redefinitions, DOES support the usual ANSI escape sequences. http://www.deskwork.de:80/HOME/STUFF/ANSI.ZIP It does not display any startup messages and it is based on NNANSI. Source code is includes (assembly language) but I miss some license info. I guess it is intended to become public domain, but that may not work out if NNANSI is already GPLed. Feel free to look and test - 8k download. Oh, and it does only run on 386+ CPU, because Jcc near and MOVSD (for scrolling) are used. Suggested use: Let DIR output scroll by all the way VERY fast if you have no better "directory size" display tool ;-). To reach Konstantin, check the deskwork.de homepage for contact details. Note that he is not on freedos-devel, so you may want to BCC him if you reply to this mail. Binary is 1756 bytes, source is 23287 bytes. I think you need a VLB/PCI or better graphics card, otherwise the MOVSD for scrolling may cause troubles. So this is an ANSI which is incredibly fast, but only for machines which are incredibly fast anyway. And it is of course pretty SMALL. Eric. |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-20 00:51:44
|
Hi all! Yes, there is a new version again! And it is called 0.91l (that is indeed an L as in LAME) :-). http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ format-0.91l.zip First of all, the danger zip thing has been removed. Instead, there are three new and shiny features / "long" options. Do not ask me to use REAL long options. I am not keen on improving the getopt implementation used. /Z:seriously - this option means that you SERIOUSLY want to format that harddisk, so you will not be prompted for confirmation! /Z:mirror - this option just saves mirror data for UNFORMAT but does not actually FORMAT the drive. Note that the mirror data is written to a fixed location (how would you find it back otherwise?) and that FORMAT shows no mercy if that location (end of the partition) is already used by other data... /Z:unformat - this option "plays back" the recorded mirror data. So it does just what UNFORMAT will do. As usual, an UNFORMAT which is not done to repair an accidental FORMAT will in most cases just trash your FAT and your root directory! Root directory restore is limited to 1 cluster in the FAT32 case. So FreeDOS FORMAT 0.91L now contains all the functionality of MIRROR and UNFORMAT for all FAT types (FAT12, FAT16, FAT32). Actually, MIRROR has the extra ability to save the partition table and UNFORMAT *should* (not yet!) have the ability to do "RECOVER drive" restoration if no mirror data exists, so the tools are still useful in their standalone versions. Explanation: RECOVER drive will *zap* the root directory and FAT and then try to restore it. Either from mirror data (usually works okay if mirror is recent) or by scanning the whole drive for directories and doing a global UNDELETE (very risky). Our FreeDOS 1.0 TODO list, as far as I know, only asks for RECOVER file mode - RECOVER drive mode is just too risky, and it is a synonym for UNFORMAT /"without mirror data" anyway. RECOVER file mode means "try to recover some files" and is basically the same as UNDELETE. The suggestion is to include that functionality in CHKDSK (SCANDISK). Talking about SCANDISK... Jim Tabor, listen, our SCANDISK is crap. It should be REMOVED from the distro until it is turned into an user interface for our very nice CHKDSK filesystem checker (even has surface scan. For FAT32, you have to have an 386+ CPU and enough RAM and use DOSDOSFSCK-2.8-FAT32 instead!) ... It is a known bug that SCANDISK just *looks* nice but hangs at once. Okay. So far for that. Last goodie in FORMAT 0.91L: It does the drive LOCK and UNLOCK automatically if DOS version 7 or newer (Win9x...) is detected now. If FORMAT should now work in all aspects except - 720k floppy format - inability to format harddisks under WinNT/Win2000/WinXP (??) - problems caused by the underlying DOS (cluster size 64k, FAT > 16 MB big) under all relevant host (Win-) DOS versions for all FAT types (12/16/32) and has acceptable speed and makes all relevant versions of CHKDSK and DOSFSCK and (not FreeDOS-!) SCANDISK happy enough now, THEN I would like to release it officially as FORMAT 0.92 (finally!). So please get your test systems ready and start testing ;-). Win2000 problems are by design of Win2000, and cluster size selection should be done in correct way by the kernel (e.g. WinXP can use 64k clusters and it can use FAT32 > 16 MB FAT size, but Win9x cannot), so I am not planning to make FORMAT able to override this decision. Support for 720k floppy format in 1440k drives (and 360k format in 1200k drives, probably!?) will be added at a later point. Lots of settings are done for floppy sizing, but it seems that I have forgotten some (done: 13.17 13.18 DDTP 13.0 13.5)... Happy FORMATing! Eric. PS: FreeDOS MIRROR / UNFORMAT seems to use another data format. Would be better if FORMAT was compatible to that, but because MIRROR is FAT16 only anyway and FORMAT can "mirror" and "unformat" FAT12 and FAT32 as well, I think "better FORMAT is compatible to its own unformat mode than to something else which does not exist yet anyway". Feel free to find the data format differences and suggest fixes, of course (savefs.c is the place to go). |
From: James T. <jim...@ad...> - 2004-01-20 00:31:48
|
Hi! I just used scandisk with kernel 2032a, fat16, and comxswp.com. It hangs after the media check. Anyone have any ideas why? BTW, M$ Scandisk works. He He, James |
From: Patrick J. L. <pa...@cu...> - 2004-01-19 23:05:48
|
"Patrick J. LoPresti" <pa...@us...> writes: > I have another issue with FORMAT 0.91k... > > By default, my boot disk creates a 2000 megabyte FAT partition (via > "fdisk /prio:2000") and formats it. With this new version of > FORMAT, I get a warning that 64k clusters are being used and that > the file system may not be readable by MS-DOS. I am mistaken; the problem is not with FORMAT. My apologies (and thanks) to Eric who corrected me off-list. But I think there may be a kernel bug here. Under MS-DOS 6, if I invoke these commands (using FreeDOS fdisk and format): fdisk /clear 1 fdisk /prio:2000 (reboot) format /y /q /u /v: c: ...I end up with a 2000M FAT16 partition having 63,999 clusters of 32Kb each. This is what I would expect, since even old versions of DOS can handle FAT16 partitions of up to 2G or so (2^16 clusters times 2^15 bytes per cluster, give or take). If I perform the same operations under FreeDOS, I end up with a 2000Mb FAT16 partition using 32,000 clusters of 64Kb each. (This is with kernel 1.1.32a build 2032a of 2003-Dec-22, courtesy of Bernd Blaauw.) It appears that the kernel is using 64Kb clusters even though the partition is less than 2G. So this appears to be a bug in the kernel. Or am I doing something wrong? - Pat |
From: Arkady V.B. <ar...@be...> - 2004-01-19 22:41:27
|
Hi! 19-=F1=CE=D7-2004 16:40 _l...@ga... (Luchezar Georgiev) wrote to fre...@li...: LG> Don't worry, Eugene Roshal is a Russian and lives in Russia, and as f= ar as I LG> know the Russian law prohibits using encryption by unauthorised peopl= e in LG> Russia at all, but doesn't ban its export ;-) In Russia, you should get the license (from FAPSI, now splitted betw= een DoD and FSB) to present crypto services _for government organizations_. N= o other restrictions. |
From: Patrick J. L. <pa...@us...> - 2004-01-19 21:36:13
|
I have another issue with FORMAT 0.91k... By default, my boot disk creates a 2000 megabyte FAT partition (via "fdisk /prio:2000") and formats it. With this new version of FORMAT, I get a warning that 64k clusters are being used and that the file system may not be readable by MS-DOS. Sure enough, the file system is not readable by MS-DOS. But worse, I can no longer run winnt.exe to install Windows because the large cluster size causes the files to take up too much space. Reverting to an earlier version of FORMAT fixes this issue, both for FreeDOS and MS-DOS 6. I will probably switch to using FAT32 eventually anyway. But this still seems like a bug; FreeDOS FORMAT ought to be able to format a FAT partition under 2G such that MS-DOS can read it. (Right?) - Pat |
From: Paul B. <san...@gl...> - 2004-01-19 19:13:35
|
On Mon, 2004-01-19 at 02:30, Luchezar Georgiev wrote: > On Sun, 18 Jan 2004 23:10:52 +0100 (MET), Eric Auer wrote: <SNIP> > Well, risking to start a "religious" or political flame war here (for which please excuse me!), I can't just turn "deaf ears" to the above text. Furst, although ZIP is STILL the most popular archive format (by tradition!), it's long since obsolete, which is admitted by the InfoZip people (in fact, NOT admitted only by PKWARE ;-) RAR has for example a much better format allowing solid archives, error correction, much stronger encryption and so on. Did I say "encryption"? The "encryption" present in PKZIP if a pile of CRAP. I say this because I've used one of the many available programs for ZIP cracking with the powerful "known plaintext attack" to crack some annoying encrypted ZIP in a few minutes. Try to do this with RAR! And what's the point in distributing a "non-cripled" ZIP when its "encryption" is so weak?! For more information about this issue, see this quote from http://gd.tuwien.ac.at/utils/archivers/infozip/FAQ.html#crypto : > ZIP format is good enough, it's been around ages, everything in the world can read it, so what's the reason for getting rid of it? I've had too many issues trying to read RAR archive under linux that I don't want to go there. Paul |
From: Luchezar G. <lu...@ga...> - 2004-01-19 16:53:43
|
On Mon, 19 Jan 2004 10:27:25 -0500 (EST), Steve Nickolas wrote: > Turbo C has a 32-bit integer type, of course - the long int. ;) So not impossible :) Of course! Not only Turbo C, "long" is a standard C type, so a "#define int long" should work ;-) > And with no freeware let alone O/S DOS RARing tool that I am aware of, I > would not like to see RAR as the compression format of choice, being that > this is an O/S DOS. UNRAR is open source but not RAR. So if we chose RAR, UNRAR would be OK to include. But as we've chosen ZIP <sigh>, RAR has nothing to do with FreeDOS, so unfortunately I have to agree with you! Lucho |
From: Steve N. <uso...@ve...> - 2004-01-19 15:27:49
|
At Mon, 19 Jan 2004 4:40pm +0200, Luchezar Georgiev wrote: > Hi, > > > The mini-extractor will be fine for the virtual > > installer boot floppy to put on, especially if it is 808x compatible and > > therefore suitable for the "people who cannot boot from CD-ROM boot disk" > > as well. > > Exactly. UNZJR *can* be 8086-compatible as "tiny inflate" is in C, > albeit its "int" is 32-bit :-{ Turbo C has a 32-bit integer type, of course - the long int. ;) So not impossible :) > > If we can do so under GPL, we should add RAR and UNRAR to the distro > > RAR and UNRAR are too big to be added to anythig but the CD-ROM edition, > and RAR is shareware :-( And with no freeware let alone O/S DOS RARing tool that I am aware of, I would not like to see RAR as the compression format of choice, being that this is an O/S DOS. -uso. -- --{note}-- --{note}-- You may wish to e-mail me at <do...@do...> as some people's addresses seem to be rejected by my ISP's mail server. However, this is my normal mail address <uso...@ve...> |
From: Luchezar G. <lu...@ga...> - 2004-01-19 14:44:34
|
Hi, > The mini-extractor will be fine for the virtual > installer boot floppy to put on, especially if it is 808x compatible and > therefore suitable for the "people who cannot boot from CD-ROM boot disk" > as well. Exactly. UNZJR *can* be 8086-compatible as "tiny inflate" is in C, albeit its "int" is 32-bit :-{ > If we can do so under GPL, we should add RAR and UNRAR to the distro RAR and UNRAR are too big to be added to anythig but the CD-ROM edition, and RAR is shareware :-( > (but then it would have to be crypto-free again??). Don't worry, Eugene Roshal is a Russian and lives in Russia, and as far as I know the Russian law prohibits using encryption by unauthorised people in Russia at all, but doesn't ban its export ;-) > If I understand > you right, the UNZIP / DEcrypto can now legally be part of the distro even > on US servers? Then we should replace the "dumb" UNZIP / UNZIP16 by the > full versions, indeed. I think it doesn't matter, and I don't think there is a "crippled" version of UNZIP anymore. > I remember that I did have the source of PKUNZJR or PCUNZJR or similar, Interesting! How did you obtain it? Disassembling that < 3K thing?! ;-) Do you still keep it? ;-) > and I remember that it did not support all compressions, so I guess the > new version by Joergen Ibsen, http://www.ibsensoftware.com/files/ tinf100.zip > ... will be a good thing to have. Glad you agree! The only question is, who will write UNZJR??? > I am AGAINST self-extracting-exe-ZIPs > because they may attract viruses and people generally do not GUESS that the > file, while being callled exe, can be extracted with an unZIPer under non-DOS > operating systems. People may instead try to run the EXE and be surprised that > it unpacked itself in whatever the current working directory was at that time. I think that you're probably right. > If the tiny extractors cannot handle SHRINK / IMPLODE, then how do I tell ZIP > to avoid those? Or is Info-ZIP unable to use them at all anyway? Steve noted it can't SHRINK, and IMPLODE was only used by PKZIP 1, so ZIP sure can't do it either. Lucho |
From: Steve N. <uso...@ve...> - 2004-01-19 14:05:46
|
At Mon, 19 Jan 2004 1:53pm +0100, Eric Auer wrote: > I remember that I did have the source of PKUNZJR or PCUNZJR or similar, > and I remember that it did not support all compressions, so I guess the > new version by Joergen Ibsen, http://www.ibsensoftware.com/files/ tinf100.zip > ... will be a good thing to have. I am AGAINST self-extracting-exe-ZIPs > because they may attract viruses and people generally do not GUESS that the > file, while being callled exe, can be extracted with an unZIPer under non-DOS > operating systems. People may instead try to run the EXE and be surprised that > it unpacked itself in whatever the current working directory was at that time. I remember that Hitech C for CP/M-80 was packed in an LHA self-extractor, and they mentioned about how to extract on a couple other OSes... > If the tiny extractors cannot handle SHRINK / IMPLODE, then how do I tell ZIP > to avoid those? Or is Info-ZIP unable to use them at all anyway? InfoZip can't use Shrink. Also, I don't think it ever compresses with Implode. -uso. -- --{note}-- --{note}-- You may wish to e-mail me at <do...@do...> as some people's addresses seem to be rejected by my ISP's mail server. However, this is my normal mail address <uso...@ve...> |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-19 12:53:35
|
Hi Lucho, I think ZIP / UNZIP may be "stone age", but still I have MANY zip files and I do exchange them with others, so I DO want to be able to do more than unzipping. The mini-extractor will be fine for the virtual installer boot floppy to put on, especially if it is 808x compatible and therefore suitable for the "people who cannot boot from CD-ROM boot disk" as well. If we can do so under GPL, we should add RAR and UNRAR to the distro (but then it would have to be crypto-free again??). If I understand you right, the UNZIP / DEcrypto can now legally be part of the distro even on US servers? Then we should replace the "dumb" UNZIP / UNZIP16 by the full versions, indeed. I remember that I did have the source of PKUNZJR or PCUNZJR or similar, and I remember that it did not support all compressions, so I guess the new version by Joergen Ibsen, http://www.ibsensoftware.com/files/ tinf100.zip ... will be a good thing to have. I am AGAINST self-extracting-exe-ZIPs because they may attract viruses and people generally do not GUESS that the file, while being callled exe, can be extracted with an unZIPer under non-DOS operating systems. People may instead try to run the EXE and be surprised that it unpacked itself in whatever the current working directory was at that time. If the tiny extractors cannot handle SHRINK / IMPLODE, then how do I tell ZIP to avoid those? Or is Info-ZIP unable to use them at all anyway? Eric. |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-19 12:43:23
|
Hi Lucho, I have played with ZIP decryptors myself, I know how weak the encryption is. You tell it yourself: It is nominally 96 bits, but I think you get an hash collission after 2^40 or 2^56 tries or something, and this is already the WORST case. Easier is making assumptions about the keyword and trying all combinations until the checksum works out. This can still take hours to days if you don't know what file format to expect (no known plaintext). I personally use ZIP "rot13" like: The encryption prevents virus scanners and keyword greppers from reading the contents, and it does tell people "I do not want everybody to open this file". But if somebody is determined to do so, or if I forget the key, I can find it back by brute force. For real encryption, as you say, you can use RAR or GnuPG or PGP. I am not going to argue about US laws, so I suggest to put full DOS ZIP binaries as an ADD-ON only on the non-US servers. I think zip -e is weak but pretty useful, so the add-on seems to be a good idea. Even if you only use it to protect some downloads on your homepage from search engines or something (not everybody has access to the .htaccess config which is - on Apache - a much better way to protect parts of homepages, although not from other users of the same web server). By the way, about protection: You may know that our campus-wide MX has a stupid spam IP filter. If you get blocked by that, complain with the Post- master at rz.uni-saarland.de ... or try reaching me at the faculty MX by sending your mail to ... @ mail.coli.uni-sb.de ... (note the MAIL. ...). Eric. |
From: Luchezar G. <lu...@ga...> - 2004-01-19 10:08:40
|
On Mon, 19 Jan 2004 10:02:49 +0100, tom ehlert wrote: > noone cares that it's obsolete. It's good enough *for software distribution*. Period. OK, OK - peace!!! ;-) Well, if the ZIP format is firmly set-in-stone for FreeDOS distribution, I'm putting up with that. But then I have an idea: As only UNZIP (not ZIP!) needs to be distributed with FreeDOS, what about using the open source "tiny inflate" library released 2 months ago by Joergen Ibsen (http://www.ibsensoftware.com/files/tinf100.zip) to create a 4-5K open source equivalent of the under 3K PKUNZJR.COM? It will take much less space on the distribution disks than UNZIP. So even on the distribution diskette the files may be ZIPped and then UNZIPped "on demand" by the installer. No knowledge of data compression is needed for UNZIPJR, just good C or Assembler programming skills. So, are there any volunteers to write such a tool? Alternatively, use self-extracting ZIPs made by ZIP2EXE with the -j option (creating a PKSFXjr mini-stub, essentially a PKUNZJR in a ZIP archive ;-) IMHO it would be perfectly legal to do so. But then a single ZIP containing all the software is better as it takes space only for a single stub (NOT so with UNZJR). And it's not open source :-( Note that only the DEFLATE and STORE compression methods can be used in the ZIPped files. SHRINK and IMPLODE are NOT supported neither by the "tiny inflate" library nor by PKUNZJR nor PKSFXjr. Lucho |