2012 Project Wish List

[Czerno]

IKB yes. 2KB yes. 4KB no.

Dear RLoew, are you saying that the MS-DOS kernel (without those patches of yours) doesn't work properly with a max_sector_size (in list-of-lists) of 4 Kibytes ?

Would you care to explain where the problem is, exactly ? I tried and ran with max_sector_size increased up to 4096, both MSDOS 6.22 and 7.10, work buffer as well as regular buffers in HMA were indeed 4k and, behold, the system seemed to work properly - at least I coumdn't crash it in an admittedly short test session.

How is one supposed to expose the bug, assuming there is a bug in the kernel which manifests itself with 4k sectors (this is what you've been telling us, right?) - I'm not talking of the utilities, format, defrag and the rest....

Regards

--

Czerno

[rloew]

IKB yes. 2KB yes. 4KB no.

Dear RLoew, are you saying that the MS-DOS kernel (without those patches of yours) doesn't work properly with a max_sector_size (in list-of-lists) of 4 Kibytes ?

Would you care to explain where the problem is, exactly ? I tried and ran with max_sector_size increased up to 4096, both MSDOS 6.22 and 7.10, work buffer as well as regular buffers in HMA were indeed 4k and, behold, the system seemed to work properly - at least I coumdn't crash it in an admittedly short test session.

How is one supposed to expose the bug, assuming there is a bug in the kernel which manifests itself with 4k sectors (this is what you've been telling us, right?) - I'm not talking of the utilities, format, defrag and the rest....

Regards

--

Czerno

I was referring to Windows 9x, not DOS. DOS can handle 16K Block Devices, 32K with my Patches. The existing Disk Driver only recognizes 512 Byte Sectors though.

None of the BIOSes I have could handle my 3TB USB Drive which used 4KB Logical Sectors. Most don't recognize it. One refused to Boot.

I have not tried any of the DOS USB Drivers.

[Czerno]

I was referring to Windows 9x, not DOS. DOS can handle 16K Block Devices, 32K with my Patches.

Ah, you meant Windows, not DOS. This would be your VFAT.VXD mod, right ?

The existing Disk Driver only recognizes 512 Byte Sectors though.

Are we back to DOS ? Are you referring to the standard driver in IO.SYS / MSDOS.SYS ?

ISTM the standard dos disk driver utilises whatever sector size is specified in the BPB, unit per unit.

None of the BIOSes I have could handle my 3TB USB Drive which used 4KB Logical Sectors. Most don't recognize it. One refused to Boot.

My computer BIOSes won't do that either, unsurprisingly ...

I have not tried any of the DOS USB Drivers.

Thought you said you had. Well, the USBASPI.SYS version I use handles 4k sectors properly through the USB (using SCSI commands of course).

I'll now try to modify - or rewrite - the block device (DIDD1000.SYS) as soon as I'm fully confident that DOS 7.10 kernel does work properly with 4 kibyte sectors.

On another note, there may be renewed efforts by the FreeDOS team to make large sectors "happen" there too...

I'll keep you all updated.

--

Czerno

Edited January 16, 2012 by Czerno

[rloew]

I was referring to Windows 9x, not DOS. DOS can handle 16K Block Devices, 32K with my Patches.

Ah, you meant Windows, not DOS. This would be your VFAT.VXD mod, right ?

I Patched DOS to work up to 32K and VFAT.VXD to work up to 4K.

The existing Disk Driver only recognizes 512 Byte Sectors though.

Are we back to DOS ? Are you referring to the standard driver in IO.SYS / MSDOS.SYS ?

ISTM the standard dos disk driver utilises whatever sector size is specified in the BPB, unit per unit.

Yes I was. The disk driver in IO.SYS totally ignores the Sector Size in the BPB.

None of the BIOSes I have could handle my 3TB USB Drive which used 4KB Logical Sectors. Most don't recognize it. One refused to Boot.

My computer BIOSes won't do that either, unsurprisingly ...

I have not tried any of the DOS USB Drivers.

Thought you said you had. Well, the USBASPI.SYS version I use handles 4k sectors properly through the USB (using SCSI commands of course).

I meant with the 3TB drives. I did some tests a while ago with smaller drives.

I'll now try to modify - or rewrite - the block device (DIDD1000.SYS) as soon as I'm fully confident that DOS 7.10 kernel does work properly with 4 kibyte sectors.

On another note, there may be renewed efforts by the FreeDOS team to make large sectors "happen" there too...

The Large Sector Mods I made were in the Disk Driver and Boot Code, so a User supplied Block Device should work with DOS 7.

Edited January 16, 2012 by rloew

[herbalist]

Since this is a wish list, is anyone willing to restart development on this Open Source Fatsec Security Driver?

Description:

Emulate filesystem security on Windows 9x systems with FAT16/32 filesystems. Files, directories, and drives can be assigned read/write/execute permissions which are enforced by a kernel-mode driver. Configuration file is locked while the driver is loaded.

This was discussed about 3 years ago here but there wasn't much interest at the time. Now that there's almost no AV support for 98, maybe it should get another look.

[Czerno]

Yes I was. The disk driver in IO.SYS totally ignores the Sector Size in the BPB.

With all due respect, this assertion makes little sense. The MS driver does use the bytes per sector value from the BPB copy made at sysinit time (part of what some DOS leaked source code calls BDSs).

I believe unpatched MS-DOS will access and mount an internal disk (anything that doesn't require a special Config.sys driver) w/ big sectors properly.. Does it not in your experience ? While you were developing your TB+ pack, did your tests include a (real or simulated) internal fixed HD with 4k sectors ?

OTOH a drive that requires a (Config.sys or later) driver, there is a (small) problem with unpatched MS-DOS, because the max_bytes_per_sec_of_any_block_device is fixed before config.sys is executed. Is this what you had in mind above and what your patch addresses ?

The Large Sector Mods I made were in the Disk Driver and Boot Code, so a User supplied Block Device should work with DOS 7.

I'm not considering booting at this stage of the little project, only the mount of an external (USB) disk using as little supplementary code as possible...

Edited January 17, 2012 by Czerno

[rloew]

Yes I was. The disk driver in IO.SYS totally ignores the Sector Size in the BPB.

With all due respect, this assertion makes little sense. The MS driver does use the bytes per sector value from the BPB copy made at sysinit time (part of what some DOS leaked source code calls BDSs).

Correcting what I said earlier. I should have said the Disk Partition Scanner ignores the Sector Size, not the Disk Driver.

Since the Table built by the Scanner is used to create the BPBs use by the Disk Driver, the Disk Driver never sees the original BPBs on the Disk Partitions.

The Sector size is defaulted to 512 Bytes. If you have any doubt, change the Sector Size field of a Partition to 4K and reboot. With an Unpatched IO.SYS, the Partition will still function as if you never changed it.

There is also a bug in the Disk Driver, but it only affects CHS Partitions.

I believe unpatched MS-DOS will access and mount an internal disk (anything that doesn't require a special Config.sys driver) w/ big sectors properly.. Does it not in your experience ? While you were developing your TB+ pack, did your tests include a (real or simulated) internal fixed HD with 4k sectors ?

As mentioned above, Unpatched DOS will not recognize internal drives as having other than 512 Byte Sectors, so big Sectors will not work.

I do not have a real Disk using 4KB Logical Sectors, so I used an Emulator.

I include a Large Sector emulation DDO in my TBPLUS Pack. This allow users to use a single 3TB hard drive directly (SATA) or through USB interchangeably.

OTOH a drive that requires a (Config.sys or later) driver, there is a (small) problem with unpatched MS-DOS, because the max_bytes_per_sec_of_any_block_device is fixed before config.sys is executed. Is this what you had in mind above and what your patch addresses ?

Not so. The Maximum Block Size is not set until after CONFIG.SYS is processed. This was intentional as User Drivers are not constrained to use 512 Byte Blocks. I also include a Driver File that allows the Maximum Block Size to be set at will. This is used if Reformatting to a larger Sector Size or inserting a Large Sector Floppy after Boot. I did Patch the code to increase the maximum Block Size possible to 32K. It was 16K.

The Large Sector Mods I made were in the Disk Driver and Boot Code, so a User supplied Block Device should work with DOS 7.

I'm not considering booting at this stage of the little project, only the mount of an external (USB) disk using as little supplementary code as possible...

I know. I was indicating that you have a good chance of success.

Be aware that you will need to return a 4KB Sector BPB in your Device Driver when CONFIG.SYS is processed. Also don't use CHS Partitions on any of these Drives.

Edited January 18, 2012 by rloew

[Czerno]

Correcting what I said earlier. I should have said the Disk Partition Scanner ignores the Sector Size, not the Disk Driver.

Since the Table built by the Scanner is used to create the BPBs use by the Disk Driver, the Disk Driver never sees the original BPBs on the Disk Partitions.

The Sector size is defaulted to 512 Bytes. If you have any doubt, change the Sector Size field of a Partition to 4K and reboot. With an Unpatched IO.SYS, the Partition will still function as if you never changed it.

Makes sense now. The MS init module checks sector size inside the PBR and marks the partition invalid if other than 512 bytes. How many pigs did Gates have to hire to produce that kind of code ?

Thanks for this and the other heads-up (or should it be heads-ups ?).

I know. I was indicating that you have a good chance of success.

Be aware that you will need to return a 4KB Sector BPB in your Device Driver when CONFIG.SYS is processed. Also don't use CHS Partitions on any of these Drives.

I'll make limited efforts, while I hope to persuade the FreeDOS types to get their kernel right.

Can you (anyone) tell if DR/Open DOS -especially versions which recognise FAT32 - can cope with 4K sectors ?

Edited January 18, 2012 by Czerno

[jumper]

The following discussion has Wish List written all over it. Would it be possible to limit the resources available to an app in any way other than to hook the various allocation and creation APIs to fail if the calling process has reached its limit?

I hate to change the subject but I'm really getting fed up with the 98se networking and internet features. I'm wanting to replace it with win2k or even ME'S network and internet. But I forgot if that can be done, can someone help me on this. And maybe it could be in the SP or it can be an individual pack.

??? Have you tried starting another topic and telling what your problem is? I have no problems with them...

Yes I did, but with that topic I talked about something alittle different. Its called Wifi connection issues in the main page of the 9x forum. But there I talk about

how my adaptor likes to crash and also how Opera crashes sometimes for no reason. I suspect the most problem here is with memory leak control, these programs are

not being set to any memory limit. Which is why I also propose a program created alike kernelex which has a tab that can give you the control to limit how much memory a program can use. I believe they have this for DOS programs. Anyway I was able to find better drivers and a better realtek progam for my adaptor. So thats pretty much fixed, and I will try some different versions of opera, but without memory limits there is no telling if it will run and not crash atleast twice a day.

Anyway, lets go back to the project at hand above which is spanish support and if anyone likes the idea of a memory limit program so we can try an get a handle on 98's memory leaks and memory address errors (BSOD), Please start a new topic. I am just learning programing so I wont start that topic. but someone more skilled can, I dont care who takes credit just as long as we keep making 98 better. Thanks and sorry for the interuption.

mrsk565, you talked about .bat files, which can be launched with all sorts of options stored in their .pif shortcut.

I don't know why they restricted that to bat files and didn't extend that to all executables.

That would be great. Bat files take so little resources that's irrelevant now. That was for time when computers worked with less than 16 Mb of ram...

It's not restricted to .bat files, it applies to all dos executables as well and it applies only to bat and dos programs because a new dos virtual machine is created when you run one of those.

You think we're on to something here ? I mean when it comes to programs and how they work we really are not sure when they may decide to crash the system. Many with the web browsers. I haven't had many crashes on other things, and when I have I was working with settings to my wifi adaptor and network stuff (no big deal though i was messing around). I don't know if its a flash issue because pages have alot of flash ads and flashly little clips like from walmart. Whatever it maybe this fix we are talking about may not fix the program from crashing. But it will save the whole system from going down and having to reboot. And lets put in a little pop-up that says this program will crash in 20sec. enough time to save and close without trouble

Or set peramitors to not allow any operation a program may do, that may exceed the mem limit set by the user.

[jds]

You think we're on to something here ? I mean when it comes to programs and how they work we really are not sure when they may decide to crash the system. Many with the web browsers. I haven't had many crashes on other things, and when I have I was working with settings to my wifi adaptor and network stuff (no big deal though i was messing around). I don't know if its a flash issue because pages have alot of flash ads and flashly little clips like from walmart. Whatever it maybe this fix we are talking about may not fix the program from crashing. But it will save the whole system from going down and having to reboot. And lets put in a little pop-up that says this program will crash in 20sec. enough time to save and close without trouble

Or set peramitors to not allow any operation a program may do, that may exceed the mem limit set by the user.

FreeRAM XP Pro 1.52 (despite what its name suggests, it runs on W9X and is freeware) has a feature similar to what you want. It will pop-up when system resources are below a pre-defined limit and let you close tasks, and prepare for a reboot before things become unstable. BTW, I don't know if its main intended function, to automatically free memory, has any side effects, so I've disabled this feature for now.

Joe.

[mrsk565]

jumper, on Yesterday, 08:29 PM, said:

I don't know if its main intended function, to automatically free memory, has any side effects, so I've disabled this feature for now.

Thank you very much for the program suggestion, I will give it a try and be aware of your advice about the auto-free memory feature.

[halohalo]

Mozilla Release Engineering team will begin upgrading to Visual Studio 2010, so Firefox 12 will be the final supported Firefox release for Windows 2000.

http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.html

[loblo]

Mozilla Release Engineering team will begin upgrading to Visual Studio 2010, so Firefox 12 will be the final supported Firefox release for Windows 2000.

http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.html

Latest release of Firefox fork Palemoon appears to be built with MSVC2010 already and it runs fine if using the hacked msvcr100.dll I posted a little while ago.

http://www.mediafire.com/?49bc54r28b94w0x

[mrsk565]

Too many new cpu's now support dual-proccesing or multi-core quad octo-core and so on. So to only be able to use one core is a waste for newer computers and no one will use 9x. Plus we haven't fixed BSOD'S, Microsoft plugged those holes in 2k and the codename whistler xp betas. If we find out what they did then maybe we could apply those fixes or files which stablize the OS. Of course these are just some thoughts, But may I ask what is holding us back from putting multi-threading into 9x ? Please be discriptive.

[rloew]

Too many new cpu's now support dual-proccesing or multi-core quad octo-core and so on. So to only be able to use one core is a waste for newer computers and no one will use 9x. Plus we haven't fixed BSOD'S, Microsoft plugged those holes in 2k and the codename whistler xp betas. If we find out what they did then maybe we could apply those fixes or files which stablize the OS. Of course these are just some thoughts, But may I ask what is holding us back from putting multi-threading into 9x ? Please be discriptive.

Windows 9x's Kernel is designed around a single "Current" Thread, Context, etc. Using multiple Cores would require a significant redesign of the Kernel as all of the routines would have to choose among an array of Current Threads, Contexts etc. Synchronization also becomes much more complicated.

After acquiring a Multi-Core Processor, I decided that a simpler approach was needed. I decided on an API that can run Threads independently from Windows and provides basic Coordination Functions. My Multi-Core API provides basic management of Threads in the other Cores. Higher level coordination of these Threads is the User's responsibility as Windows does not even know the other Threads exist.