rloew

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.

@PROBLEMCHYLD: I have updated my PATCHPAR Program to properly handle Windows ME. The Patch for IOSYS 7 has not changed, you do not need to update again.

JFYI : http://reboot.pro/2362/page__st__31 jaclaz Noted. I may have to PM future experimental programs to the intended users. The combined Patch used Phellum's patches to force LBA processing. When Logical Partitions are processed as LBA, the OFF field is the actual starting point of the Partition and the FLG field contains 00000001. My Patches do not include his, so CHS processing is still enabled. When Logical Partitions are processed as CHS, the OFF field is relative to a Start Cylinder. The MSW of the FLG field is this Start Cylinder. Your F:, G: and I: Logical Partitions are CHS. The problem with my older Patch is that it didn't cover your case where the Linux Partition on Disk #1 was processed as CHS and then Discarded. The Start Cylinder leaked into the FLG field for the next Partition processed, your H: Partition. If you compare the PARTSX outputs from my old and new Patches you will see the difference. I identified a similar problem and fixed it with my earlier Patch, but you uncovered another one. I have corrected the problem with Patching the unpacked Windows ME IOSYS 8 and attached it here. PATCHPAR.ZIP

Well, Mr Loew, I've just downloaded and this one works properly for me. Joe. Perfect New version will be added to Service Pack 3 ================================================== Filename : WINBOOT.SYS MD5 : 94d9415346382faef754ca943e6759dd SHA1 : ba48cf1b40fc820fce708afee87f732cbfc6a04e CRC32 : 82380988 SHA-256 : c86124aace28c02fcde58e967f91c3930097247a107b22dba6b542fb817f623c SHA-512 : eb3b3cff053c24bdda018832d5e2da2f8e292132f20e0c3a771f33cbb57923898697814a35ce9799c5cb80ed133ed1cb37ee4ca56c34a26531f836150024958b Full Path : C:\WINBOOT.SYS Modified Time : 1/28/2012 7:55:13 PM Created Time : 1/28/2012 7:57:05 PM File Size : 222,670 File Version : Product Version : Identical : Extension : SYS File Attributes : A ================================================== Jumping the gun a bit, but it should be OK as long as you weren't one of the four who downloaded it before 7:15 PM EST I am removing the previous versions from the Forum as they do not cover all possible configurations of Partitions.

I see no one listens. Four people downloaded the experimental PATCHPAR I posted earlier. I said not to download it before it was verified. I have already redone it. @jds: If you already downloaded it, redownload the newer copy in my previous post and use it instead.

I believe the following combination of Partitions caused the problem 1. On Drive #1 you have a Type 5 Extended Partition. 2. The last Logical Partition in this Extended Partition is Non-DOS. 3. On Drive #2 you have a Type 0xF Extended Partition. 4. The Logical Partition in this Extended Partition is DOS. It is a rather improbable combination but I have revised my Patch so it should cover it. Try the attached Patch on an Unpatched copy of IO.SYS and boot with the Patched IO.SYS Test all of your Partitions and run PARTSX again. EDIT: This Patch has been revised and has been tested. IMPORTANT: Four copies were downloaded before 7:15 PM EST. Do not use these copies are they do not cover all cases. REEDIT: The Patch did not correctly handle Windows ME and has been removed. A new Patch will be posted shortly. Patches to IOSYS 7 are fine.

Everything looks normal. H: should have worked properly. Were you running my Patched IO.SYS when you ran PARTSX or the working version? Either way, switch to the other one and rerun PARTSX.

I have updated my PATCHPAR Program to Patch the Unpacked Windows ME IO.SYS as well. You will need to get the Unpacker from my Website. Let me know if it solves your problem. Hi Mr. Loew. Well, I decided to give this a try on my home PC and unfortunately, ran into a problem. My drive H: (in DOS 7.1, without loading the W98SE GUI) produced the following from a DIR command : Volume in drive H is \é)ÞŠ†¥pÊ Directory of H:\ y‹³æ"bx 2Àí 3,273,781,586 06/04/89 11:37 1 file(s) 3,273,781,586 bytes 0 dir(s) 446.52 MB free By contrast, your earlier partial patch together with my favourite two byte patches to IO.SYS produces the following : Volume in drive H is 2-3-FLAKEY Volume Serial Number is 07EA-4466 Directory of H:\ MUSIC <DIR> 14/01/10 0:43 VIDEO <DIR> 14/01/10 1:21 TH99 <DIR> 01/02/10 0:41 CDDA <DIR> 31/03/10 23:03 FTP <DIR> 17/12/10 20:06 CAMERA <DIR> 31/05/11 20:56 TEMPOR~1 <DIR> 01/06/11 23:26 0 file(s) 0 bytes 7 dir(s) 361.72 MB free The physical drive in question has the following partition table entries : 06 FAT16 (Primary) E7 RS (Primary) 0F Extended Partition (LBA) 83 EXT2 (Primary) The extended partition has a single volume (logical drive H:) : 0B FAT32 (LBA by virtue of the extended partition type) All other drives and volumes work OK with either set of patches. Joe. I have not been able to replicate this problem. What is the layout of the first Drive? Run the attached program from DOS 7.1 and post the result.

I have created two new formats using 1KB Sectors. A 10 Sector per Track (1.6MB) Bootable HD Floppy and an 11 Sector per Track (1.76MB) Non-Bootable HD Floppy. A mixed format could hold 1.759MB and be Bootable. A 1.92MB Floppy using three 4KB Sectors per Track can be created, but is very unreliable.

I am not aware of issues with Scanners but there is sometimes a memory issue with network drivers particularly Gigabit Ethernet. Try my RAM Limitation Patch Demo using the /M Option. It only allows 10 Minutes per boot so you will need to test it quickly and uninstall it promptly.

Fortunately CreateFontA has been in GDI32 since Win32s so we don't need a stub for it. We can cross other bridges when we come to them. i knew it didn't need a stub. It was an example of what is out there. I had redirected USER32.DLL and GDI.DLL through a logging DLL I was experimenting with, so I had a list of the APIs and their parameter counts. It was the largest. I don't have a list. I wrote a tool that extracts the APIs from the header files and helps build source code for the loggers I mentioned above.

You will need to cover more than 9 parameters. CreateFontA uses 14 parameters. There probably are larger ones elsewhere.

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. 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. 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. 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.

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. 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. My computer BIOSes won't do that either, unsurprisingly ... 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. 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.

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.

Yes , that is expected (collisions when cloning in some situations), I was talking of actual "by chance" collisions, more curiosity than anything else, the ID is 4 bytes, thus min 00000000 and max FFFFFFFF, i.e. 4,294,967,296 available values, but 4,294,967,296 to 1 against though pretty rare is not "nearly impossible", and since the ID/Volume serial is not "random" but is calculated, as seen on the little "reversing" spreadsheet I made: chances are much bigger that that. jaclaz I have never noticed an accidental non-cloned collision. Since they are typically generated from the current date, a non-cloned collision can only occur in one of four ways. 1. Using a formatter that zeroes the ID or sets it to a specific value. 2. Using Partitions formatted with different algorithms. Rare unless #1 is true. 3. Sharing disks with someone else who formatted at the exact same time. 4. Formatting two partitions within a second of each other. This happened when I first added my anti-collision code to RFDISK. It updated multiple Partitions to the same ID..

An E90000 is not? Of course it is. I didn't mention it because you already had it covered when you said "Start with E9". Yes, hopefully you have only one of these mounted at a time, but generating a "random" ID is not a problem and "safer". BTW and OT, ever heard of a "collision"? Of course I have. Collisions are a big problem if you clone a drive and have both present. My next release of RFDISK has built in checking and repair options for Collisions.

Naaah, I don't think there is any conspiracy , just "normal" stupidity/crazyness of non-standards or undisclosed/undocumented properly ones....... Didn't say anyone actually did, but it is another opportunity. EBxx90 is OK. Valid BPB from 0xB to 0x40 for FAT32. DOS will support a FAT32 Superfloppy, Windows will not. Signature must be 0x29 for proper operation with Windows 9x. ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID. System ID can be "FAT32". I've mentioned most of my related findings in the last few Posts. Most of my research was concentrated on adding Terabyte support and Large Sector support. I haven't done much research on Floppies or SuperFloppies. There are additional Kernel components involved with them as well.

No, I thought that DOS 7.1 would have done for the moment. Not quite. Windows does it's own checking in IOS.VXD and VFAT.VXD so there is room for more discrepancies. I have already created Partitions that looks like FAT12 to one and FAT16 to the other. And what about this? http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html Doesn't change anything but adds one more thing to worry about. I've seen the code that does these checks in my research. For FAT12 and FAT16. FAT32's BPB ends at 0x40. Some of the eBPB is also validated such as the Signature Byte. The ID is important to Windows for Volume discrimination. Yep , but as seen we need to have at least EB0090 or E90000 even on a "no code" bootsector (just as you posted ) for the tested MS OS's, while this is happily ignored by FreeDOS. Yep , but as seen we need to have at them for FreeDOS anyway, while the tested MS OS's happily ignore them. Last two items seems to me like a nice contradiction (and no-end loop kind of situation). On the other hand it provides a nice way to have volumes that are accessible/mountable only on FreeDOS (AND NOT on MS OS's)..... and another kind of volume that can be accessed only on MS OS's (AND NOT on FreeDOS) .... pretty much unuseful, if you ask me, but still some interesting news. (and also a way to have a volume accessible from XP - and possibly later - MS OS 's, BUT NOT from DOS 7.x - and possibly earlier) jaclaz Another scheme to enforce DRM?

You make it sound a little bit too obvious and B/W for my tastes. There is a whole lot of shades of grey. http://reboot.pro/15878/ They are required if you want general compatability. I never said you couldn't scrounge up something that could read them. No Windows 9x tests? The BPB is the block starting at Offset 0xB only. The Jump Bytes are part of the Code and FAT Validation. The Magic Bytes are for Boot Sector Validation only. In a non-Bootable Partition or disk, the Jump Destination does not matter.

1. 2TB 2. Yes, from Windows ME. But why bother? 3. A. All Logical Partitions are within an Extended Partition. There is no room to make them Primary Partitions. 4. Yes.

I have written an API that supports multi-core. At present it does require that Applications be written to use the API. I was looking at the idea of running Virtual PC (or a better option if Kex and Import patcher make that possible) on its own processor while the rest of the system runs on the first processor. Would this require a complete rewrite of VPC? It may be possible to push Windows 98 entirely into another Core. I was able to push DOS, except for Interrupt Code, into any Core I wanted. I'm not sure there would be much advantage to running VPC in another Core. Windows XP and up support Multi-Core so they would run VPC in the Base Core and push everything else into the other Cores producing the same result.

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted. It must be: JMP SHORT NOP or JMP LONG The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing. Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

Western Union is not quite that bad but it is not cheap. I had a few people in Europe buy my earlier High Capacity Disk Patch for $10 and Western Union cost them about $9. Money Orders are problematical unless they are International Postal Money Orders recognized by the United States Postal Service. Although they recognize a number of South American Countries, plus Japan, they do not recognize Uruguay. Sorry dencorso, Brazil is also not on the list.

I always accepted Paypal. I just did not accept Credit Card based payments. Now that they charge fees on everything, and I added the $1 S&H to cover it, I think they have removed the 5 per year restriction on Credit Cards. If you must use a Credit Card funded Paypal Payment, I will accept it this one time to find out. If the restriction is gone, I will revise my terms for payment to allow them. C. C. Anderson has a Merchant Account with Paypal, so she never had a limit on Paypal Credit Card Payments. Anyone interested in being a Distributor is welcome.