You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(58) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(102) |
Feb
(196) |
Mar
(162) |
Apr
(127) |
May
(126) |
Jun
(70) |
Jul
(138) |
Aug
(187) |
Sep
(77) |
Oct
(86) |
Nov
(146) |
Dec
(77) |
2005 |
Jan
(85) |
Feb
(132) |
Mar
(179) |
Apr
(177) |
May
(151) |
Jun
(134) |
Jul
(323) |
Aug
(230) |
Sep
(202) |
Oct
(176) |
Nov
(199) |
Dec
(76) |
2006 |
Jan
(200) |
Feb
(106) |
Mar
(132) |
Apr
(112) |
May
(194) |
Jun
(160) |
Jul
(249) |
Aug
(212) |
Sep
(199) |
Oct
(133) |
Nov
(100) |
Dec
(63) |
2007 |
Jan
(65) |
Feb
(63) |
Mar
(142) |
Apr
(91) |
May
(138) |
Jun
(194) |
Jul
(120) |
Aug
(146) |
Sep
(85) |
Oct
(85) |
Nov
(90) |
Dec
(170) |
2008 |
Jan
(141) |
Feb
(69) |
Mar
(51) |
Apr
(67) |
May
(183) |
Jun
(144) |
Jul
(118) |
Aug
(96) |
Sep
(135) |
Oct
(135) |
Nov
(85) |
Dec
(164) |
2009 |
Jan
(131) |
Feb
(186) |
Mar
(318) |
Apr
(313) |
May
(53) |
Jun
(216) |
Jul
(93) |
Aug
(139) |
Sep
(50) |
Oct
(64) |
Nov
(55) |
Dec
(62) |
2010 |
Jan
(74) |
Feb
(42) |
Mar
(52) |
Apr
(73) |
May
(87) |
Jun
(32) |
Jul
(40) |
Aug
(71) |
Sep
(66) |
Oct
(42) |
Nov
(37) |
Dec
(38) |
2011 |
Jan
(84) |
Feb
(48) |
Mar
(86) |
Apr
(94) |
May
(139) |
Jun
(141) |
Jul
(210) |
Aug
(123) |
Sep
(125) |
Oct
(197) |
Nov
(87) |
Dec
(113) |
2012 |
Jan
(260) |
Feb
(95) |
Mar
(159) |
Apr
(222) |
May
(216) |
Jun
(133) |
Jul
(80) |
Aug
(83) |
Sep
(180) |
Oct
(43) |
Nov
(176) |
Dec
(154) |
2013 |
Jan
(165) |
Feb
(151) |
Mar
(102) |
Apr
(65) |
May
(101) |
Jun
(85) |
Jul
(106) |
Aug
(71) |
Sep
(22) |
Oct
(82) |
Nov
(123) |
Dec
(102) |
2014 |
Jan
(69) |
Feb
(24) |
Mar
(39) |
Apr
(41) |
May
(123) |
Jun
(83) |
Jul
(86) |
Aug
(159) |
Sep
(58) |
Oct
(79) |
Nov
(73) |
Dec
(112) |
2015 |
Jan
(78) |
Feb
(91) |
Mar
(93) |
Apr
(37) |
May
(222) |
Jun
(233) |
Jul
(42) |
Aug
(53) |
Sep
(82) |
Oct
(30) |
Nov
(97) |
Dec
(18) |
2016 |
Jan
(87) |
Feb
(140) |
Mar
(86) |
Apr
(91) |
May
(154) |
Jun
(127) |
Jul
(121) |
Aug
(60) |
Sep
(48) |
Oct
(11) |
Nov
(19) |
Dec
(64) |
2017 |
Jan
(139) |
Feb
(51) |
Mar
(76) |
Apr
(130) |
May
(522) |
Jun
(45) |
Jul
(30) |
Aug
(55) |
Sep
(1) |
Oct
(33) |
Nov
(116) |
Dec
(27) |
2018 |
Jan
(159) |
Feb
(38) |
Mar
(59) |
Apr
(81) |
May
(6) |
Jun
(57) |
Jul
(127) |
Aug
(60) |
Sep
(29) |
Oct
(45) |
Nov
(61) |
Dec
(39) |
2019 |
Jan
(55) |
Feb
(18) |
Mar
(6) |
Apr
(6) |
May
(67) |
Jun
(56) |
Jul
(78) |
Aug
(86) |
Sep
(175) |
Oct
(56) |
Nov
(107) |
Dec
(75) |
2020 |
Jan
(62) |
Feb
(29) |
Mar
(305) |
Apr
(69) |
May
(84) |
Jun
(92) |
Jul
(48) |
Aug
(130) |
Sep
(126) |
Oct
(65) |
Nov
(103) |
Dec
(224) |
2021 |
Jan
(191) |
Feb
(119) |
Mar
(200) |
Apr
(416) |
May
(171) |
Jun
(283) |
Jul
(42) |
Aug
(27) |
Sep
(45) |
Oct
(82) |
Nov
(119) |
Dec
(156) |
2022 |
Jan
(133) |
Feb
(137) |
Mar
(196) |
Apr
(26) |
May
(62) |
Jun
(90) |
Jul
(135) |
Aug
(77) |
Sep
(91) |
Oct
(33) |
Nov
(86) |
Dec
(60) |
2023 |
Jan
(59) |
Feb
(20) |
Mar
(92) |
Apr
(22) |
May
(16) |
Jun
(46) |
Jul
(65) |
Aug
(95) |
Sep
(36) |
Oct
(67) |
Nov
(65) |
Dec
(30) |
2024 |
Jan
(88) |
Feb
(94) |
Mar
(111) |
Apr
(106) |
May
(71) |
Jun
(71) |
Jul
(68) |
Aug
(124) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Nicholas B. <nic...@nd...> - 2024-08-22 05:13:22
|
Thank you. On Wed, Aug 21, 2024 at 10:22:41PM -0400, Jerome Shidel via Freedos-user wrote: > JEMM has been updated since FreeDOS 1.3 was released. > > I recommend updating that program. Or, try using the monthly interim test build of FreeDOS. The interim test build contains the latest versions we have of the programs provided with the OS. > > > > On Aug 21, 2024, at 5:05 PM, Nicholas Bernhard via Freedos-user <fre...@li...> wrote: > > > > I recently pulled a Dell Inspiron 1150 from my local landfill. This is a Windows XP-era laptop. It has an Intel Celeron 2.6 GHz, and I installed 2 GB of RAM. > > I was able to install FreeDOS on it, but it will only run in safe mode. The other options (JEMMEX, JEMM386, etc.) freeze on their loading screens. Specifically, I'll get the message 'JemmEx v5.79 [02/02/20]', and then a blinking cursor indefinitely. > > Not sure if this has to do with safe mode, but I can only get sound from the 'bell', I can't play MP3s. > > One additional bit of information: I have tried installing 32-bit Haiku OS on the laptop, and that has not worked, either. > > > > My question: is this a) something wrong in the hardware, b) something wrong in FreeDOS, or c) expected behavior? I remember installing FreeDOS on a 701C, and even that was able to play an MP3, albeit verrrry slowly. > > > > As it stands, I can run Vim, I can run games, and I can read AMB-format e-books, so it is usable for me. > > > > Thanks, > > > > Nicholas > > > > > > > > _______________________________________________ > > Freedos-user mailing list > > Fre...@li... > > https://lists.sourceforge.net/lists/listinfo/freedos-user > > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user |
From: Jerome S. <je...@sh...> - 2024-08-22 02:23:05
|
JEMM has been updated since FreeDOS 1.3 was released. I recommend updating that program. Or, try using the monthly interim test build of FreeDOS. The interim test build contains the latest versions we have of the programs provided with the OS. > On Aug 21, 2024, at 5:05 PM, Nicholas Bernhard via Freedos-user <fre...@li...> wrote: > > I recently pulled a Dell Inspiron 1150 from my local landfill. This is a Windows XP-era laptop. It has an Intel Celeron 2.6 GHz, and I installed 2 GB of RAM. > I was able to install FreeDOS on it, but it will only run in safe mode. The other options (JEMMEX, JEMM386, etc.) freeze on their loading screens. Specifically, I'll get the message 'JemmEx v5.79 [02/02/20]', and then a blinking cursor indefinitely. > Not sure if this has to do with safe mode, but I can only get sound from the 'bell', I can't play MP3s. > One additional bit of information: I have tried installing 32-bit Haiku OS on the laptop, and that has not worked, either. > > My question: is this a) something wrong in the hardware, b) something wrong in FreeDOS, or c) expected behavior? I remember installing FreeDOS on a 701C, and even that was able to play an MP3, albeit verrrry slowly. > > As it stands, I can run Vim, I can run games, and I can read AMB-format e-books, so it is usable for me. > > Thanks, > > Nicholas > > > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user |
From: Rugxulo <ru...@gm...> - 2024-08-21 23:57:34
|
Hi, On Wed, Aug 21, 2024 at 2:17 PM Eric Auer via Freedos-user <fre...@li...> wrote: > > but you also have to keep track of whether the values > are up to data. Win9x does that by forcing you to > explicitly shut down instead of powering off. Each > time you fail to do that, it has to read the entire > FAT on the next boot to re-compute FSinfo values. > > You do not want to force DOS users to explicitly > shut down before they power off. Why not? I long ago got into the habit of running "fdapm poweroff" to shutdown. Actually, I aliased it to "halt". (One of my computers, my old Lenovo desktop, does actually support APM. But none of the others do.) |
From: <fre...@pa...> - 2024-08-21 22:23:51
|
May I please get your best links on creating an LPT1 port to a networked printer via Microsoft’s net tools? On Wed, Aug 21, 2024 at 2:29 PM, Eric Auer via Freedos-user - freedos-user at lists.sourceforge.net <[fre...@pa...](mailto:On Wed, Aug 21, 2024 at 2:29 PM, Eric Auer via Freedos-user - freedos-user at lists.sourceforge.net <<a href=)> wrote: > Hi! > >> I recently pulled a Dell Inspiron 1150 from my local landfill. >> This is a Windows XP-era laptop... Intel Celeron 2.6 GHz, and >> I installed 2 GB of RAM. I was able to install FreeDOS... but... > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html > > Well, if JEMMEX and JEMM386 do not run out of the box, > have you tried reading their documentation? Maybe there > are some command line options for JEMMEX or JEMM386 to > *manually* configure them in an Inspiron-friendly way. > > If that does not work, you should *at least* try to get > some form of HIMEM working. HIMEMX, QMGR, FDXMS, FDXMS286, > any XMS and HMA will be better than none, because that > will help you to have more DOS RAM free and you can use > most caches and ramdisks when you have XMS :-) > > Even XMS drivers may need *manual* configuration, because > some hardware and/or BIOS variants can fail to offer or > properly setup auto-detectable A20 gates or memory maps. > >> I can only get sound from the 'bell', I can't play MP3s. > > The problem is that most classic games expect SoundBlaster > era soundcards. Your laptop has something more modern, so > you have to use VSBHDA, SBEMU or similar for games and old > media players. Some newer media players for DOS can work > directly with AC97 or HDA compatible sound hardware such > as the hardware I expect your laptop to have. As usual, > you will have to read the docs carefully to select the > right ingredients and configuration to get sound to work. > > Regards, Eric > > PS: You can use PCISLEEP to find what sound the Dell has. > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user |
From: Eric A. <e....@jp...> - 2024-08-21 21:29:38
|
Hi! > I recently pulled a Dell Inspiron 1150 from my local landfill. > This is a Windows XP-era laptop... Intel Celeron 2.6 GHz, and > I installed 2 GB of RAM. I was able to install FreeDOS... but... https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html Well, if JEMMEX and JEMM386 do not run out of the box, have you tried reading their documentation? Maybe there are some command line options for JEMMEX or JEMM386 to *manually* configure them in an Inspiron-friendly way. If that does not work, you should *at least* try to get some form of HIMEM working. HIMEMX, QMGR, FDXMS, FDXMS286, any XMS and HMA will be better than none, because that will help you to have more DOS RAM free and you can use most caches and ramdisks when you have XMS :-) Even XMS drivers may need *manual* configuration, because some hardware and/or BIOS variants can fail to offer or properly setup auto-detectable A20 gates or memory maps. > I can only get sound from the 'bell', I can't play MP3s. The problem is that most classic games expect SoundBlaster era soundcards. Your laptop has something more modern, so you have to use VSBHDA, SBEMU or similar for games and old media players. Some newer media players for DOS can work directly with AC97 or HDA compatible sound hardware such as the hardware I expect your laptop to have. As usual, you will have to read the docs carefully to select the right ingredients and configuration to get sound to work. Regards, Eric PS: You can use PCISLEEP to find what sound the Dell has. |
From: Nicholas B. <nic...@nd...> - 2024-08-21 21:04:43
|
I recently pulled a Dell Inspiron 1150 from my local landfill. This is a Windows XP-era laptop. It has an Intel Celeron 2.6 GHz, and I installed 2 GB of RAM. I was able to install FreeDOS on it, but it will only run in safe mode. The other options (JEMMEX, JEMM386, etc.) freeze on their loading screens. Specifically, I'll get the message 'JemmEx v5.79 [02/02/20]', and then a blinking cursor indefinitely. Not sure if this has to do with safe mode, but I can only get sound from the 'bell', I can't play MP3s. One additional bit of information: I have tried installing 32-bit Haiku OS on the laptop, and that has not worked, either. My question: is this a) something wrong in the hardware, b) something wrong in FreeDOS, or c) expected behavior? I remember installing FreeDOS on a 701C, and even that was able to play an MP3, albeit verrrry slowly. As it stands, I can run Vim, I can run games, and I can read AMB-format e-books, so it is usable for me. Thanks, Nicholas |
From: Michał D. <mo...@gm...> - 2024-08-21 19:37:36
|
Hello, I would discount Avast and Avira as real antivirus programs because they have reliably false flagged open source projects (FuhQuake, ezQuake, etc) and cracked game executables. Best regards, Michał Dec W dniu 21.08.2024 o 21:13, Ralf Quint via Freedos-user pisze: > Yeah, that's one of the things were AVast (and other AV applications > too) has gotten really bad. Anything that even remotely looks like > "messing" directly with the hard drive is being flagged as potentially > malicious. Same goes for a lot of self-developed software, simply due > to the fact that the AV scanners are trying to detect malware not > based on actual malware code, but common library code used by standard > compilers. This might be less of a problem these days for "modern" > Windows or Linux code, specially when written using MS compilers (or > gcc in case of Linux), because it is very common. But DOS based code > is rather rare these days, less samples for the AV scanners and thus a > higher rate of false positives... :( > > > Ralf > > > > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user |
From: Eric A. <e....@jp...> - 2024-08-21 19:17:28
|
Hi Rugxulo, as you already found out, FAT16 is limited to 64k files per partition and 128 kB (usually 256 sectors) per FAT. Only rather small FAT16 drives use far less than 64k clusters. Most drive sizes differ mainly in how large clusters are. With the usual side-effects. FAT32 usually has way more clusters and way larger FAT, making it very slow to read the whole FAT to figure out how much disk space is used and free. *Cached FAT* You can improve speed by loading a cache, preferably with read-ahead, before you start doing "large" stuff with the FAT. If I remember correctly, I even have an example in the LBACACHE and TICKLE docs where you deliberately DIR /S > NUL to get all FAT and directory info in the cache, so it already is cached when you need it again later. Poor man's "copy disk to RAMDRIVE" ;-) *Cached disk usage info* You are right that Win9x buffers the answer to that in https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FS_Information_Sector but you also have to keep track of whether the values are up to data. Win9x does that by forcing you to explicitly shut down instead of powering off. Each time you fail to do that, it has to read the entire FAT on the next boot to re-compute FSinfo values. You do not want to force DOS users to explicitly shut down before they power off. However, you could implement something similar to the following in DOS: I. When DOS gets asked for used/free disk space: 1. if DOS has the answer in RAM, return that 2. else read FSinfo and FAT headers to see if FSinfo values are up to date. If yes, return values and keep a copy of the answer in RAM :-) 3. else read entire FAT to compute values, return them and, again, keep a copy in RAM. For all cases (1, 2, 3) also update a copy of the values in FSinfo and set a flag there and/or in FAT headers, unless drive is R/O. Only write FSinfo and FAT headers on disk if the write would really change values! II. When the FAT gets updated in a way which has an effect on used/free disk space: Reset the mentioned flag in FSinfo and/or FAT headers, to indicate values are no longer up to date, but do update used/free count in RAM. Only write the flag to disk if it actually did change! Use a copy in RAM to keep track of it. III. You can also trigger FSinfo updates on disk for a few selected other events, such as file system sync / flush calls or apps exiting via int 21.4c / int 20 etc. Regards, Eric |
From: Ralf Q. <fre...@gm...> - 2024-08-21 19:13:31
|
Yeah, that's one of the things were AVast (and other AV applications too) has gotten really bad. Anything that even remotely looks like "messing" directly with the hard drive is being flagged as potentially malicious. Same goes for a lot of self-developed software, simply due to the fact that the AV scanners are trying to detect malware not based on actual malware code, but common library code used by standard compilers. This might be less of a problem these days for "modern" Windows or Linux code, specially when written using MS compilers (or gcc in case of Linux), because it is very common. But DOS based code is rather rare these days, less samples for the AV scanners and thus a higher rate of false positives... :( Ralf |
From: Liam P. <lp...@gm...> - 2024-08-21 14:01:43
|
On Wed, 7 Aug 2024 at 05:30, Trevor Campbell via Freedos-user <fre...@li...> wrote: > > I am trying to resurrect an old Amstrad PC-1512, which is an 8086 > machine with 640K mem. Brave man! FWIW, possibly the optimal DOS for that machine would be DR-DOS 3.41. It's as small as MS-DOS 3.3. All later DOSes (MS or IBM PC DOS 4, 5, 6, FreeDOS, etc.) take more base memory and rely on tricks with high/upper memory on 2386 and 386 chips to sideline most of it. DR-DOS 3.4 does >32MB disks and has command editing and things, but it's tiny and is the smallest but richest DOS for an 8088/8086 PC. Only the upgraded PC-1512 (and the later PC-1640) had 640kB of course. Stock models had 512kB, thus the number in the model name. Which makes this even more important. There's a tenuous historical justification: the PC-1512 shipped with DR DOS-Plus in the box, which is an ancestor of DR-DOS. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lp...@ci... ~ gMail/gTalk/FB: lp...@gm... Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 |
From: Rugxulo <ru...@gm...> - 2024-08-21 08:22:45
|
Hi, On Mon, Aug 19, 2024 at 3:00 PM tom ehlert via Freedos-user <fre...@li...> wrote: > > > In particular, if you say it takes 30 secs., I would blindly hope a > > partition half that size would take only half as long to calculate. > Unlikely as the size of the FAT remains exactly the same. A FAT16 partition of 500 MB would still be limited to maximum 65536 files, right? > > I have some very small and simple ASM code that calculates free space > > (8086, int 21h 36h) and another (386, FAT32 with LFNs, int 21h 7303h). > > Feel free to ask for it (public domain). > > Wow. ASM code !! By Ruxulo!! > How do you think FreeCOM gets the free space on disk? Instead of relying on (or rebuilding) an entire shell, the simple code for this could be isolated and run (or modified) independently. > > But you're saying it's not the slow DIV instruction (to get decimal > > output) holding things up. If that were the holdup, you could just > > output hexadecimal (no slow DIV needed). > > ... should be able to deduce that it's not the time for the DIV instruction as this time > remains the exact same when it's done later a second time. But DIV is slow enough (or irrelevant?) that many RISC cpus don't include a hardware DIV instruction. So it is an actual slowdown that is, in many cases, not strictly needed. Right? * https://stanislavs.org/helppc/div.html " Clocks: 808x / 286 =============== reg8 80-90 / 14 reg16 144-162 / 22 mem8 (86-96)+EA / 17 mem16 (150-168)+EA / 25 " Lest anyone say that modern cpus don't care, the OP did in fact specifically mention 8086 hardware. DIV may be considered an acceptable slowdown, but it is a slowdown nonetheless. > > Doesn't FAT32 already keep the amount of free space stored somewhere? > No, And for a good reason. > DOS crashes regularily, with no opportunity to write back this number to the disk before shutting down. Maybe I'm thinking of backup boot sector (or some such). * https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FS_Information_Sector "The 'FS Information Sector' was introduced in FAT32 for speeding up access times of certain operations (in particular, getting the amount of free space). It is located at a logical sector number specified in the FAT32 EBPB boot record at position 0x030 (usually logical sector 1, immediately after the boot record itself)." (N.B. The OP could not get FAT32 to work successfully.) |
From: Mateusz V. <ma...@vi...> - 2024-08-20 19:05:19
|
On 20/08/2024 20:43, Ben Collver via Freedos-user wrote: > I tried EtherDFS and it seems clean and stable. Thanks for the > recommendation! If you do not need to access the same drive from multiple machines at the same time, then you might want to try ethflop <https://ethflop.sourceforge.net/>. It is simpler and smaller, provides "floppy-like" disks of up to 31M. It acts at the block level, so it's even more transparent to applications than etherdfs (which acts at the file level). Another advantage of ethflop is that if you keep data across different "virtual floppies", a virus won't be able to wipe everything. You can also mount the virtual floppies read-only for extra protection. Mateusz |
From: Ben C. <ben...@ri...> - 2024-08-20 18:45:51
|
> Date: Fri, 16 Aug 2024 14:49:21 -0400 > From: je...@sh... > To: FreeDOS Users <fre...@li...> > Subject: Re: [Freedos-user] Copying Files Between Linux And FreeDOS > > Have you considered using EtherDFS or NetDrive? > > https://etherdfs.sourceforge.net/ <https://etherdfs.sourceforge.net/> I tried EtherDFS and it seems clean and stable. Thanks for the recommendation! |
From: Eric A. <e....@jp...> - 2024-08-19 20:18:47
|
Hi Tom, Rugxulo et al, To comment on the underlying performance bottleneck: For FAT32 drives, the FAT itself is huge. Which means it takes time to process it, for example to find out how many clusters are free. It actually comes with a filesystem info sector with places where you can store that count, so you do not have to browse the whole FAT each time you want to know. You can also keep the value in RAM, of course. The problem is that if you do not trust the FSinfo data, you have to read the whole FAT (either during boot or) when the first app calls the API which tells how much free space you currently have on some FAT drive. This will take a long time, and in particular if you do not have a large enough cache loaded at that moment, it will not even have the side-effect of caching the FAT for whatever you want to do with the FAT later, for example growing a file etc. Given how unpleasant all of this is for performance, you might understand why Win9x keeps a copy of the whole FAT in RAM :-p Which in turn made Win9x unable to work with FAT32 drives if they have too many clusters in relation to RAM size, I think. Either way, you cannot have 8086 compatibility, FAT32 drives and good performance at the same time. Just pick your pain ;-) As said, if you can delay the big counting of free clusters until you have loaded a cache, preferably one with read-ahead to compensate for DOS only looking at one FAT sector at a time, then you can reduce the pain. IF you have 386+ and much RAM. >> Doesn't FAT32 already keep the amount of free space stored somewhere? > No, And for a good reason. > DOS crashes regularily, with no opportunity to write back > this number to the disk before shutting down. That is why Windows keeps a flag on whether you have properly closed (unmounted) a drive. If you have, it can still trust the FSinfo data to some degree. DOS could do something similar. If I remember correctly (from dosfsck) the flag is stored in the 0th entry of one of the FAT copies, or the FSinfo sector? >> No slow calculation at bootup needed. > This is not at bootup, but at the first time > "free disk space" is requested. Which is typically when you first use DIR after boot, I guess. Regards, Eric |
From: tom e. <te...@dr...> - 2024-08-19 20:00:12
|
>> > After boot the first time I run a `DIR` command e.g. >> > The directory list returns quickly, but the number of bytes free takes another 30 seconds to appear. >> > Subsequent `DIR` commands return immediately whether in the same directory or elsewhere. > In particular, if you say it takes 30 secs., I would blindly hope a > partition half that size would take only half as long to calculate. Unlikely as the size of the FAT remains exactly the same. > I have some very small and simple ASM code that calculates free space > (8086, int 21h 36h) and another (386, FAT32 with LFNs, int 21h 7303h). > Feel free to ask for it (public domain). Wow. ASM code !! By Ruxulo!! How do you think FreeCOM gets the free space on disk? > But you're saying it's not the slow DIV instruction (to get decimal > output) holding things up. If that were the holdup, you could just > output hexadecimal (no slow DIV needed). Even idiots should be able to deduce that it's not the time for the DIV instruction as this time remains the exact same when it's done later a second time. >> That's something in the design of DOS/FAT. >> When the machine boots, it doesn't know the amount of free clusters on the disk. >> >> When asked about free disk space, it has to read the entire FAT and count the number of unused clusters. >> And it does so one sector of FAT data after he next sector. that's no problem on a FAT16 drive with at most >> 256 sectors in the FAT, but can be a problem for large FAT32 drives. >> >> After this first time, DOS remembers the number of free clusters and keeps track of them over >> creat, write, delete operation so it is much faster. > Doesn't FAT32 already keep the amount of free space stored somewhere? No, And for a good reason. DOS crashes regularily, with no opportunity to write back this number to the disk before shutting down. > No slow calculation at bootup needed. This is not at bootup, but at the first time "free disk space" is requested. Tom |
From: Michał D. <mo...@gm...> - 2024-08-19 10:38:34
|
It's literally in the 2nd link under every email. W dniu 19.08.2024 o 12:19, brian hite via Freedos-user pisze: > Please remove from this email chain > > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user |
From: brian h. <ski...@ho...> - 2024-08-19 10:35:30
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">Please remove from this email chain</div> |
From: Rugxulo <ru...@gm...> - 2024-08-19 02:28:06
|
Hi, On Wed, Aug 14, 2024 at 5:46 AM tom ehlert via Freedos-user <fre...@li...> wrote: > > Hallo Herr Trevor Campbell via Freedos-user, > > am Mittwoch, 14. August 2024 um 01:10 schrieben Sie: > > > I have Freedos installed on 8086 hardware using an SD Card with a 1Gb FAT-16 partition. > (I have so far been unable to get a FAT-32 partition to work) So the FAT32 kernels don't boot on 8086 for you?? Have you tested older (e.g. 2041) kernels? Surely some should work. (Actually, maybe it's a BIOS issue.) > > After boot the first time I run a `DIR` command e.g. > > The directory list returns quickly, but the number of bytes free takes another 30 seconds to appear. > > Subsequent `DIR` commands return immediately whether in the same directory or elsewhere. A large 1 GB FAT16 partition is somewhat wasteful due to cluster size being 16 kb, IIRC. For my use, a lot of stuff is backup .ZIP files, hence data that is secondary and not actively used. So it's probably better to use two smaller FAT16 partitions (8 kb clusters?), each roughly 500 MB or smaller. (With a lot of files, wasting 16 kb for a simple 100-byte file is ridiculous and adds up.) In particular, if you say it takes 30 secs., I would blindly hope a partition half that size would take only half as long to calculate. I have some very small and simple ASM code that calculates free space (8086, int 21h 36h) and another (386, FAT32 with LFNs, int 21h 7303h). Feel free to ask for it (public domain). But you're saying it's not the slow DIV instruction (to get decimal output) holding things up. If that were the holdup, you could just output hexadecimal (no slow DIV needed). > That's something in the design of DOS/FAT. > When the machine boots, it doesn't know the amount of free clusters on the disk. > > When asked about free disk space, it has to read the entire FAT and count the number of unused clusters. > And it does so one sector of FAT data after he next sector. that's no problem on a FAT16 drive with at most > 256 sectors in the FAT, but can be a problem for large FAT32 drives. > > After this first time, DOS remembers the number of free clusters and keeps track of them over > creat, write, delete operation so it is much faster. Doesn't FAT32 already keep the amount of free space stored somewhere? No slow calculation at bootup needed. |
From: Jerome S. <je...@sh...> - 2024-08-19 00:52:24
|
Out of curiosity, I submitted the download URL to VirusTotal. 1 out of 96 online scanners flagged it as "Malicious" That was Sucuri SiteCheck. So, I went over to their site and directly submitted the same URL there. It comes back as "Medium Risk" and the only reason it gives.... Scan failed, try again later. Just lovely, is it. :-) Jerome |
From: Jim H. <jh...@fr...> - 2024-08-18 23:39:40
|
On Sun, Aug 18, 2024 at 5:57 PM andrew fabbro via Freedos-user <fre...@li...> wrote: > > Is the hash different than the officially published ones? > > https://www.freedos.org/download/verify.txt > Good question. I just checked the sha512sums on the FreeDOS Files Archive at Iibiblio, comparing them to a copy of the verify.txt file. For each pair, the first line is the sha512sum of the zip file on Ibiblio; the second line is the sha512sum as reported in the verify.txt file: > $ for f in *zip; do sha512sum $f ; tail -7 ~/verify.txt | grep $f; done > 0e5f922a1601b43d421fa72a06e899542a13cbbc5833564f7d5203bb3bf0dc056b6a6d788ffff28bdf6f2c2a75d4416c4245c67072f4c9f94fd8e3f385ba7439 FD13-BonusCD.zip > 0e5f922a1601b43d421fa72a06e899542a13cbbc5833564f7d5203bb3bf0dc056b6a6d788ffff28bdf6f2c2a75d4416c4245c67072f4c9f94fd8e3f385ba7439 FD13-BonusCD.zip > 9683f4d1395d9879d836a08ee6fc875328a8896c75b85b59ec421d45c487fd106225aa9203d98a9101c8137f43b13f272c2464dd858ae494e1a5076fa1dd4903 FD13-FloppyEdition.zip > 9683f4d1395d9879d836a08ee6fc875328a8896c75b85b59ec421d45c487fd106225aa9203d98a9101c8137f43b13f272c2464dd858ae494e1a5076fa1dd4903 FD13-FloppyEdition.zip > 008cd9b7434c34f945a2c443bac2bb73515fb789b599a7047263133a9b6a4de36a9432cc664d3355f2ad76491f3204a66eb28376c19b5564da1932d40306921d FD13-FullUSB.zip > 008cd9b7434c34f945a2c443bac2bb73515fb789b599a7047263133a9b6a4de36a9432cc664d3355f2ad76491f3204a66eb28376c19b5564da1932d40306921d FD13-FullUSB.zip > e27545e8dff67be47c875e0c700eced44c94b174e1b9f55cca1a526fb96ad7e1af9c75051fc6630cf919ef5657f3c701f499f60b5bd7b908357ebf6c25b11fb2 FD13-LegacyCD.zip > e27545e8dff67be47c875e0c700eced44c94b174e1b9f55cca1a526fb96ad7e1af9c75051fc6630cf919ef5657f3c701f499f60b5bd7b908357ebf6c25b11fb2 FD13-LegacyCD.zip > 5d2bdf7533a9936b9418afaf0fe2dbbc3b96ae61825dd648b2908a6767f5cccece4128f057c7a4176dbc78491d5623c356694845868d2963aeef1cc58f1822a4 FD13-LiteUSB.zip > 5d2bdf7533a9936b9418afaf0fe2dbbc3b96ae61825dd648b2908a6767f5cccece4128f057c7a4176dbc78491d5623c356694845868d2963aeef1cc58f1822a4 FD13-LiteUSB.zip > 4eef4db28210462e30c5ba0f3764c0d9729358f258335b2385a5d43295c2149159b4cce779b6f61b68d4751368d635e66c40d941626aa3a1a755060af4b3d25f FD13-LiveCD.zip > 4eef4db28210462e30c5ba0f3764c0d9729358f258335b2385a5d43295c2149159b4cce779b6f61b68d4751368d635e66c40d941626aa3a1a755060af4b3d25f FD13-LiveCD.zip Or if you want that in a more readable way, here are the md5sums: > $ for f in *zip ; do md5sum $f ; head ~/verify.txt | grep $f; done > e9a04673e06fa14d4873d6d7db4b106c FD13-BonusCD.zip > e9a04673e06fa14d4873d6d7db4b106c FD13-BonusCD.zip > 3edecef2c585c7e471f26c7638d514f4 FD13-FloppyEdition.zip > 3edecef2c585c7e471f26c7638d514f4 FD13-FloppyEdition.zip > 873f5bb50f5007b7cd08c3e0b37cfb34 FD13-FullUSB.zip > 873f5bb50f5007b7cd08c3e0b37cfb34 FD13-FullUSB.zip > 5ef6de118e2a0b46c6756a70effc4c58 FD13-LegacyCD.zip > 5ef6de118e2a0b46c6756a70effc4c58 FD13-LegacyCD.zip > a63824d54ce286da82b4d0f38348e5a8 FD13-LiteUSB.zip > a63824d54ce286da82b4d0f38348e5a8 FD13-LiteUSB.zip > 61b5646ae7d6943a0957fd5f8c057357 FD13-LiveCD.zip > 61b5646ae7d6943a0957fd5f8c057357 FD13-LiveCD.zip So the files on the server are as expected. |
From: andrew f. <an...@fa...> - 2024-08-18 22:57:12
|
Is the hash different than the officially published ones? https://www.freedos.org/download/verify.txt On Sun, Aug 18, 2024 at 1:21 PM Petr Ullmann via Freedos-user < fre...@li...> wrote: > Hi guys, > > maybe it is false alert but when I try to download FreeDOS live CD > ( > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/FD13-LiveCD.zip) > > I get warning from Avast that the website is infected by some virus. > > Can somebody else same error? > > Thanks. > > Petr > > > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- andrew fabbro an...@fa... |
From: Jim H. <jh...@fr...> - 2024-08-18 22:35:10
|
You didn't mention the specific warning text that you see, but since this comes up once in a while (although not too frequently) I think I know what you are seeing. Yes, it is a false positive. Virus scanning software isn't always able to find an *exact* match for viruses. To try to find "zero day" viruses (in other words, to detect viruses before they are "known" viruses) antivirus programs sometimes use heuristics to guess about "virus-like" behavior. Avast is one of these antivirus programs that tries to make a guess. One "virus-like" behavior is a program that tries to install new code onto your bootloader, and run the system on its own. In other words, exactly like the SYS command will do, or how the FORMAT program can wipe a partition with a new filesystem. Or like what the FreeDOS kernel will do. Those are the kinds of "virus-like" programs that Avast thinks it finds in the FreeDOS LiveCD. This is a false positive. Avast hasn't really found a virus. On Sun, Aug 18, 2024 at 3:20 PM Petr Ullmann via Freedos-user <fre...@li...> wrote: > > Hi guys, > > maybe it is false alert but when I try to download FreeDOS live CD > (https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/FD13-LiveCD.zip) > I get warning from Avast that the website is infected by some virus. > > Can somebody else same error? > > Thanks. > > Petr > > > > _______________________________________________ > Freedos-user mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-user |
From: Petr U. <sl...@ce...> - 2024-08-18 20:20:01
|
Hi guys, maybe it is false alert but when I try to download FreeDOS live CD (https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/FD13-LiveCD.zip) I get warning from Avast that the website is infected by some virus. Can somebody else same error? Thanks. Petr |
From: Eric A. <e....@jp...> - 2024-08-18 16:41:55
|
hi! to reply on-list to an off-list request to comment some old bug tickets on sourceforge, I wrote this mail. my provider today does not want to mail to mail.com :-p i guess the x61 lbacache problem and ctmouse defaults are the only tickets which are still "actionable"? https://sourceforge.net/p/freedos/bugs/63/ lbacache freezes on via c7 in 2011, could be a himem bug, but one of the comments say the bug ticket can be closed? ==> https://sourceforge.net/p/freedos/bugs/57/ in 2010 and ==> https://sourceforge.net/p/freedos/bugs/233/ in 2019 says lbacache crashes with stack nesting on thinkpad / lenovo (t61 and) x61 computers when used with usb drives, in one case in context of an invocation of vinfo by the installer https://sourceforge.net/p/freedos/bugs/397/ feature request asking for nansi to notice and block attempts to load it twice. rather low priority IMHO? https://sourceforge.net/p/freedos/bugs/31/ something with kernel and int 24 critical error handling? ==> https://sourceforge.net/p/freedos/bugs/26/ 2009 ctmouse should change defaults for text mode mouse cursor color masks to preserve intensity/blink bits. https://sourceforge.net/p/freedos/bugs/43/ multiple 2016 complaints regarding the distro, ems, xms, kernel, mouse and various pci sound cards. could close and open fresh tickets for any topic which did not get fixed since then? https://sourceforge.net/p/freedos/bugs/104/ some VERY unspecific 2013 bug report about the mouse stopping to work on virtual box. too few details to do anything IMHO. https://sourceforge.net/p/freedos/bugs/190/ half of our apps fail to work after a 2017 usb install, maybe just a problem with usb disk access for that user? close. https://sourceforge.net/p/freedos/bugs/214/ no mouse cursor in edit if width > 80, is this still the case? for all edit and ctmouse versions? what causes it? https://sourceforge.net/p/freedos/bugs/77/ find freezes, but this seems to be an error in which syntax the user tried to use. would it have worked with MS DOS find? regards, eric |
From: Eric A. <e....@jp...> - 2024-08-18 15:54:59
|
Hi! >> I do not like dosemu2. See the [rant] section of the following post >> for details. >> >> https://www.hardwareasylum.com/articles/retro/mystic-dosemu2/page8.aspx You do not actually HAVE to compile dosemu2 yourself, there are pre- compiled versions for popular Linux distros. And you do not HAVE to use comcom or fdpp, it still supports all other DOS kernels, including of course classic FreeDOS kernels and any command.com shell you like. Dosemu2 just comes bundled with fdpp and comcom. I would only compile dosemu or dosemu2 if I had any self-made patches. And I do not agree that the process to replace kernel and shell would be undocumented. There are many comments in /etc/dosemu/dosemu.conf and making your own config in your home directory is all you need to do to get your own settings and your own DOS drives where you will be able to install any DOS you like :-) Installation can be as easy as copying kernel and shell into your Linux directory which "is" C: My personal preference is booting from a Linux DIRECTORY serving as the C: drive for DOS, plus IMAGES for FAT tools tests, for example: $_hdimage = "freedos2 fatimage.bin fatimage2.bin (and so on)" The first item is a directory, the others are disk images (made with tools which come with dosemu2) to test stuff like dosfsck and format. Other things for which I prefer to use custom settings: - size of EMS, XMS, DPMI, VGA and VESA etc. memory based on my taste - blink rate of cursor, title of window, default zoom for 320x200 - hotkey for grabbing the mouse focus, hogthreshold for CPU load - floppy images, optionally bootable, also for testing disk tools - some mouse and printer settings for testing drivers for those None of those are necessary for most users, defaults are quite ok. I have not tested the network support, so no comment on that yet. Personally, I would recommend to set a custom DOS drive, custom 320x200 zoom factor and a mouse grab hotkey you can remember ;-) You can now configure quite a bit of sound stuff, including MIDI engines, so that would probably be interesting to play with, too. For games, the usual default SB16 with Adlib etc. is good enough. Cheers, Eric |