rloew

Then why is m Win2K system's task manager showing both cores? The PROBLEM was that the task manager was set to One Graph, all CPUs, insted of one graph PER CPU. Windows 2000 supports multicore fine and all. Windows 9x has no support for Multi-Core, but I have developed an API that does. You can write Multi-Core aware Programs with it.

I was thinking of separately Compiled Assembly Code, not embedded Assembly. That is because VKRNLEX.VXD does not export any Dynacall or Win32 Services. It doesn't even have a Numerical ID. I already said for this application, the issue is cosmetic and can optionally be fixed with a Character Array.

Yes. Look at VMM.INC for more info. The array is embedded in the Struct, you can't use a pointer to it. You would have to copy the characters into the Struct directly. memcpy would run during initialization. As I said before, I cannot be sure that the Struct is not scanned or copied before initialization.

The author of that message is Microsoft. Apparently some configurations may corrupt the Display when using DOS in Safe Mode. It is unlikely to cause permanent damage. I have ignored this message hundreds of time and never had a problem worse than getting my DOS Box default position changed.

With all due respect, of course it would: when the 8th character is a space, one patches 0x00 to 0x20. But if there are 8 characters, it's simply a question of using an incomplete 7 characters string at build time, and then patching the final 0x00, added by C++, with the right value for the 8th character. Yes, but that would require generating a separate 7 Character string when the Identifier is 8 Characters. That would defeat the purpose of using the util.h Macro as is. It would also require specifying the eighth Character to the Patcher. VMM.H defines these Macros also, but Microsoft specifies a separate "quote_name" argument in addition to using a "name" argument.

Indeed, because it'll always append the EOS (NULL) character to the variable string, hence the overflow error. Do you happen to see any viable solution to this, while keeping the flexibility desired by the author? Or should we just leave it as is, waste no more time? Unfortunately, I do not know a way to get around this issue in C++. C might allow the eight character string without the null. This would not fix the padding issue. I cannot guarantee that a runtime fix would work, as I am not sure if the Descriptor is scanned or copied prior to Initialization. Using a Character array may not be flexible but it only needs to be done once for a given VXD so it can be done for KernelEx fairly easily. @dencorso: A patch would not work for eight character identifiers since the program cannot be patched if it cannot be compiled. It could only be used to fix the padding issue.

If I may ask, what are the implications of this wrong name field for the overall KernelEx operation? Since it's been introduced in 4.5.2 and that version appears to work correctly within its capabilities, could this be a big problem or it's just a cosmetic issue? Anyway, looking at the code in util.h, it all appears to be a single #define: #define _Declare_Virtual_Device(name, ver_major, ver_minor, ctrl_proc, device_num, init_order, V86_proc, PM_proc, ref_data) \ BOOL __stdcall ControlDispatcher(DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); \ \ void __declspec(naked) name##_CTRL(void) \ { \ __asm PUSH EDI \ __asm PUSH ESI \ __asm PUSH EDX \ __asm PUSH ECX \ __asm PUSH EBX \ __asm PUSH EAX \ __asm CALL ctrl_proc \ __asm CMP EAX, TRUE \ __asm RET \ } \ \ EXTERNC struct VxD_Desc_Block name##_DDB = \ { \ 0, DDK_VERSION, device_num, ver_major, ver_minor, 0, \ #name, init_order, (ULONG)name##_CTRL, (ULONG)V86_proc, (ULONG)PM_proc, \ 0, 0, ref_data, 0, 0, 0, 'Prev', sizeof(struct VxD_Desc_Block), \ 'Rsv1', 'Rsv2', 'Rsv3' \ } The name field is retrieved from the #name variable and there may be a reason why it's been made like this - flexibility comes to mind first. But given the way the structure is declared, I can't see a way to translate whatever name may be fed to the struct, into a fixed 8-byte array. Of course, using a fixed array as you mentioned above is accepted by the compiler, but the declaration loses its flexibility. What would be the best way to handle this, I wonder? In the case of KernelEx it may only cosmetic. There may not be anything searching for the VKRNLEX.VXD image in memory. Eight character names would be a problem with this definition.

Where is it ? It is in the VXD Descriptor Block. It is located at offset 0x101C in the 4.5.2 Version. It is supposed to be 8 Characters with Space padding and no termination character. Do you mean VxD_Desc_Block in util.h ? I get "C2117: 'VKRNLEX ' : array bounds overflow" when I replace #name by #name####" ". Is it really there ? Yes. In Assembly it is not a problem. In C/C++ you cannot use a string. You need to use a Character Array {'V','K','R','N','L','E','X',' '}

Where is it ? It is in the VXD Descriptor Block. It is located at offset 0x101C in the 4.5.2 Version. It is supposed to be 8 Characters with Space padding and no termination character.

You do seem to be out to get VKRNLEX.VXD specifically. It is not the Core of KernelEx. It is a Kernel Mode Loader added in 4.5.2 to load the KernelEx Hook earlier during Boot. It didn't even exist in 4.5.1. Deleting it shuts down the Core of KernelEx because the Hooks to GetProcAdress are not installed. If the new Beta Version had a problem and substituting the non-Beta Version cured it then there would be a reason to suspect it, but you did not say you did this. @Leyok I did find a minor error in VKRNLEX.VXD. The 8 Byte Module Identifier was not space padded. It was "VKRNLEX", when it should have been "VKRNLEX " (space at end).

You asked me to chime in. VKRNLEX.VXD installs the KERNEL32.DLL Hooks. I had to analyze it to resolve the conflict between KernelEx and my FILE64 and DLLHOOK Packages. You cannot blame VKRNLEX.VXD specifically because it controls most if not all of KernelEx. A problem caused by almost any part of KernelEx would disappear if VKRNLEX.VXD is removed. As far as the bickering in other Threads, that was definitely a Red Letter Day. I don't use any 98SE SP nor KernelEx. I am a Developer so I don't need any additional potential risks. I made my own SP (SP0) which has the Official Fixes for Windows 98SE. I hesitate to use even Hotfixes as they also can cause problems as Microsoft has clearly stated. I use the ESDI_506.PDR Hotfix mainly because I have reverse engineered all of the changes. Only where there is no alternative do I use ME, NT or XP Files. Even my USB Stack has been Down Versioned to mostly 98SE Files after having to install the ME Stack. U98SESP3 is written for and tested to a Windows 98SE System without KernelEx. KernelEx is written for and tested to a Windows 98SE System without U98SESP3. It is not surprising that putting them together leads to mayhem Neither is totally bug free and probably never will. The drug companies run trials on thousands of people and they still die after public release. U98SESP3 is a rapidly moving target. I haven't tried it since 3.7 which produced bugs I wasn't even looking for. When the updates slow down enough I can poke it with my Software. KernelEx, as I expected, broke FILE64 and DLLHOOK. I offer FILE64 for sale so it is a PAID Program. SInce I anticipated that DLLHOOK would be useful to KernelEx users as well as non-KernelEx users, I made it compatable with both uses. FILE64 was updated as well. Instead of bickering, both sides have to work together. The result will be many more bug fixes on both sides, and a melded Version of both.

Maybe yes, maybe no. (he does "rock", but possibly not for this specific item) To be fair: cdob posted - passing by - this info earlier, but it went unnoticed/wasn't followed (most probably at the time "we" weren't ready for it ). You must be slipping. The following post is 8 Months older.

I found only the patched version on MDGX's website so I downloaded and analyzed it. I determined the Patch author bumped the Version Number, so there is no original 2223 Version. So you can stick with the original Version. If integrating the SP, for the updated VMM, with my Patches, as described before, remove the VCACHE.VXD file installed by the SP before Reinstalling my Patches. If not, just use the Version on your backup Disk.

Is that in the system.ini file? Because I looked for MaxPhysPage/MaxFileCache entires in it after installing the pack and couldn't find any. Right now I just use a floppy to restore those 3 files (vmm, vcache, and esdi_506) after installing the pack. Is that sufficient or am I not fully restoring it? I tested an older version of the SP, so I had not verified that SYSTEM.INI changes were removed. Replacing the three files is sufficient to restore the original Patched Files. If you want the newer VMM.VXD and VCACHE.VXD, you can use the procedure I described previously to Patch them. The SP Version of VCACHE.VXD is compatable but will interfere with Installation/Uninstallation unless you ignore it by using: PATCHMEM <options> * * - You may want to get an unmodified VCACHE.VXD 2223 and overwrite the one placed by the SP before Reinstalling my Patch. Definitely. PATCHMEM checks if VMM.VXD and VCACHE.VXD already exist, and only extracts them if they don't. VMM.VXD updates preexisted the development of PATCHMEM, so I provided for them. The PATCHMEM Uninstaller will also not remove them if they existed before they were Patched.

I am not aware of any timing issues. I can run Windows 3.1 on my MA785 system in Enhanced mode. IO.SYS 7.1 needs a couple of mods to allow Windows 3.1 to run. A Patch is also needed to avoid the bad Current Directory on Exit Bug.

There may be a BIOS option to stop USB Devices from being mounted. I also have a Driver Letter Remapper that can stabilize the Letter assignments.

They overwrite them though. I have rloew's high capacity & sata patches applied to esdi_506.pdr. AFAIK, the one in the pack doesn't support sata drives. If I dont restore it before windows starts up, the system becomes unbootable. As for the memory files, I have a gigabit lan and a 256mb video card, so I have to run some special switches (with rloews patchmem) in order to get everything stable. I don't know if the files in the pack have the same tweaks applied (i've always just restored them to be safe). The SP definitely does conflict with these Patches. The SP only installs the LLXX High Capacity Patch and the Memory Workaround. The SATA Patch and the /M Option of PATCHMEM is definitely not duplicated. Available RAM will be limited to ~1GiB. The Patches can be integrated with the current SP by uninstalling them, installing the SP, and then reinstalling them without rebooting Windows. The Memory Workaround must also be removed to regain access to the full RAM.

Your BIOS is recognizing the Flash Drive and reporting it like a Hard Drive so DOS assigns a Drive Letter. Windows remounts it over the existing Drive Letter. Ejecting the Flash Drive leaves a partially deleted Drive structure.

You have a SATA Drive. This can cause this problem if you do not have my SATA Patch. To find out, go to Safe Mode and Disable, NOT Remove, everything under "Hard Disk Controllers" using Device Manager. Then try Normal Mode again. In addition your Hard Drive is bigger than 137GB. If you are using anything in the upper 23GB, you will need another Patch. Otherwise you could crash and/or corrupt your Hard Drive.

The "System" attribute makes a file unmoveable. This is from the days when some Programs implemented Copy Protection by recording the Cluster numbers of certain files so that copying would be detected by a change in the Cluster numbers used by these files. Also IO.SYS had to be locked down in early versions of DOS.

Try disabling the motherboard video.

Some things can stay, some things must be removed, some things are redetected leaving unneeded Registry entries. Determining which requires testing of every possible driver. This is not practical for a general purpose package. It is much simpler to remove all of them cleanly. Special situations, such as USB only Keyboard and Mouse, may require different handling, but that would not be part of a standard SP. At least not yet.

@peter777: Are you using the /M Option in my Demo Patch?

Patches that are required during Boot, such as my RAM Limitation Patch, High Capacity Disk Patch, Bootman or Terabyte Plus, must be installed during or possibly before Installation of Windows. They can only be installed later, as you have indicated, if you can insure that they are not needed earlier, such as by removing RAM, not partitioning above 137GB, not using SATA, etc.

I don't know where else the problem could be. I have Windows 8 x64 recently installed. I'm using a Gigabyte GA-970A-DS3 motherboard with AMD SB950 south bridge. The SATA controller is configured in AHCI mode, and I'm using the stock AHCI drivers made by Microsoft and included in Windows 8. The SATA cable is brand new and works perfectly well with my other disks (without CRC nor cabling errors) My setup is pretty standard. Nothing out of the ordinary. What could be wrong on my part??! Yes, I know, but I want something more portable, so I can carry it with me. AHCI mode is not compatable with Windows 9x. Using the SATA controller requires my SATA Patch as well as setting a different Mode. At best you would be running in compatability mode which is rather slow, regardless of what adapter you use.