defuser

On this configuration, this option does not work, as far as I understand:

Original HIMEM.SYS /v Fixed "1. 1_PS_2" /v "DOS=HIGH,UMB" is removed in this case. Only HIMEM.SYS is loaded with the single parameter "/v". HIMEM.SYS itself writes the same thing in both cases:

"PS/2". And above about the original "HIMEM.SYS".

Can you provide reference results of "A20TEST" when it is guaranteed to work correctly, in the same form as presented above? To understand how it should actually be, under normal conditions.

So which correction option is best suited for this case? I retested in combination with the new "A20TEST" variant and only with the "/V" parameter: However, the error when starting WINDOWS has not appeared again yet.

So he writes the following: and WINDOWS starts normally (without errors). The old "A20TEST" (1996) gives the same as above. And here is the new one, the link to which you gave: But I launched the original HIMEM.SYS (from 11.05.1998), as you wrote, only with the parameter "/V". Although usually (Beyond the current experiment) I also use additionally "/MACHINE:AT" (With it, the ScanDIsk disk check at the WINDOWS boot stage is MUCH faster), as well as the parameter "/NUMHANDLES=64".

For the sake of interest, I checked all this on an Intel H81: 0. 0_FIXED WARNING: The A20 Line was already enabled 1. 1_PS_2 Windows protection error. You need to restart your computer. 2. 2__A20CONTROL_OFF WARNING: The A20 Line was already enabled 2+1. 2_1_PREFERRED WARNING: The A20 Line was already enabled 3. 3__ALWAYS_ON Installed A20 handler number 19. 3+1. 3_1 Windows protection error. You need to restart your computer. (What's surprising is that the error occurs exactly once every other time.). А20TEST.EXE (From the "Undocumented PC" floppy disk from 1996) in any case it gives the following: A20 CONTROL TEST v2.00 (c) 1994, 1996 FVG ННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННН Tests the A20 gate state and keyboard controller status and the ability of the controller to change the A20 gate. When A20 is enabled, memory is accessable above 1MB. Otherwise, when A20 is disabled, the system acts like an 8088. ДДДДДДДДДДДДДДДДДДДДДДДД Test Results ДДДДДДДДДДДДДДДДДДДДДДДДД Verified ДДД Keyboard Controller ДДД A20 Test A20 State Returned State D0 Value ДДДДДДДДДДДДДДДДДДДД ДДДДДДДДД ДДДДДДДДДДДДДД ДДДДДДДД Initial State enabled disabled 49h D1 Command disable enabled disabled 49h D1 Command enable enabled disabled 49h DD Command disable enabled disabled 49h DF Command enable enabled disabled 49h

I connect to the question. I also faced a similar problem and made all sorts of attempts to solve it. Namely, two audio devices were missing from Multimedia (One on the PCI bus, and the second on the USB). On the new (Test) installation, they were naturally there (the USB device appeared even on the virtual machine). But on the old one, transferred from the previous PC - they did not appear there (And on the virtual machine, too). I've tried everything. The only thing I was able to find out for sure then was that the root of this problem is in the registry files (SYSTEM.DAT; USER.DAT). I don't remember exactly, but I think only the first one had a real impact. And yes, I was never able to beat this problem back then, trying to find the key differences. I had to perform a clean install and apply all the fixes, patches, settings again, and transfer a lot of things from the previous OS installation. But it was easier than I had feared. And it didn't take so long - I managed the main one in a day and about a week more for the final polishing, on the spot, in the process of work. Although not without surprises (It's like walking all the way through a rake again). But now everything is behind us, all the devices are now in place, everything is working relatively smoothly, as planned, and, of course, a working backup has been made.

Everything worked out. Used "LocalLoadHigh=1" + EMM386.EXE (with parameters). Now the game also starts with IO.SYS version 3.0. Returned even the old (more productive) video card. There is now enough memory, and the game starts, but only with the LH parameter (for example: "lh game.exe"). Thank you.

A small note. I checked the operation of the integrated AHCI controller and the BIOS provides a choice of three different modes of operation: "RAID Mode", "AHCI Mode" and "IDE Mode". I compared how the upper memory is consumed when choosing one of them. And here's what came out of it: "RAID Mode": V і A000h to C000h 128K VGA Video RAM і A000h to B000h 64.0K VGA Graphics і B000h to B800h 32.0K MDA Text і B800h to C000h 32.0K CGA Text/Graphics R і C000h to D800h 96K Unknown ROM і Copyright (C) 1996-2006 NVIDIA Corp. - і D800h to E800h 64K <nothing> R і E800h to EE00h 24K Unknown ROM і No copyright notice. First 84 bytes are: і і 15 00 24 00 09 00 E4 02 FF FF 37 E8 07 00 ..$.......7... і 00 00 0B 00 00 01 08 00 60 01 06 00 A0 01 ........`..... і FF FF 00 00 59 F8 00 F0 80 FC 5F 74 05 2E ....Y....._t.. і FF 2E 20 00 3C 00 75 06 BB 02 13 E9 3E 01 .. .<.u.....>. і 3C 40 75 21 80 FB 00 75 04 B0 80 EB 09 80 <@u!...u...... і FB 01 0F 85 25 01 B0 88 E8 CC 01 8A C8 80 ....%......... - і EE00h to F000h 8K <nothing> R і F000h to 0000h 64K System ROM і ROM BIOS: AMI і BIOS Date: 04/13/12 "AHCI Mode": V і A000h to C000h 128K VGA Video RAM і A000h to B000h 64.0K VGA Graphics і B000h to B800h 32.0K MDA Text і B800h to C000h 32.0K CGA Text/Graphics R і C000h to CE00h 56K Unknown ROM і Copyright (C) 1996-2006 NVIDIA Corp. - і CE00h to E800h 104K <nothing> R і E800h to EE00h 24K Unknown ROM і No copyright notice. First 84 bytes are: і і 15 00 24 00 09 00 E4 02 FF FF 37 E8 07 00 ..$.......7... і 00 00 0B 00 00 01 08 00 60 01 06 00 A0 01 ........`..... і FF FF 00 00 59 F8 00 F0 80 FC 5F 74 05 2E ....Y....._t.. і FF 2E 20 00 3C 00 75 06 BB 02 13 E9 3E 01 .. .<.u.....>. і 3C 40 75 21 80 FB 00 75 04 B0 80 EB 09 80 <@u!...u...... і FB 01 0F 85 25 01 B0 88 E8 CC 01 8A C8 80 ....%......... - і EE00h to F000h 8K <nothing> R і F000h to 0000h 64K System ROM і ROM BIOS: AMI і BIOS Date: 04/13/12 "IDE Mode": V і A000h to C000h 128K VGA Video RAM і A000h to B000h 64.0K VGA Graphics і B000h to B800h 32.0K MDA Text і B800h to C000h 32.0K CGA Text/Graphics R і C000h to CE00h 56K Unknown ROM і Copyright (C) 1996-2006 NVIDIA Corp. - і CE00h to E800h 104K <nothing> R і E800h to EA00h 8K Unknown ROM і No copyright notice. First 84 bytes are: і і 15 00 24 00 09 00 E4 02 FF FF 37 E8 07 00 ..$.......7... і 00 00 0B 00 00 01 08 00 60 01 06 00 A0 01 ........`..... і FF FF 00 00 59 F8 00 F0 80 FC 5F 74 05 2E ....Y....._t.. і FF 2E 20 00 3C 00 75 06 BB 02 13 E9 3E 01 .. .<.u.....>. і 3C 40 75 21 80 FB 00 75 04 B0 80 EB 09 80 <@u!...u...... і FB 01 0F 85 25 01 B0 88 E8 CC 01 8A C8 80 ....%......... - і EA00h to F000h 24K <nothing> R і F000h to 0000h 64K System ROM і ROM BIOS: AMI і BIOS Date: 04/13/12 In total, they remain available for user tasks under these conditions when using the built-in AHCI controller (Including +32.0K MDA): - In "RAID Mode" - 104КБ upper memory free; - In "AHCI Mode" - 144КБ upper memory free; - In "IDE Mode" - 160KB upper memory free;

In general, yes, the problem was aggravated by a video card that was too late (I wonder if it is possible to somehow edit its vBIOS in such a way that it would take up a little less address space?). Replaced the video card. I also cleaned it up a little. And now it turned out like this (If you don't ship anything there): It is necessary to take up all this space now in some optimal way... I prefer to play this particular game under WINDOWS (There is already a separate MS-DOS and there are games there, there are no problems, but TBPLus is not needed there). And here we need to somehow make it so that not only our patient fits in this upper memory, but also the regular "EMS Page Frame" (96 KB approximately after loading takes up a sum), so that it would also be there (The game requires it just too)! What is the best way to do this? For example, this is how they managed to take up all the space in DOSBOX (Where the dots are displayed in my screenshot, they just have a PageFrame loaded there)? By the way, while I was testing all this a little, I noticed that in a virtual machine (Virtual PC 5.2) in no version 9x "EMS Page Frame" is loaded (Even in release 95 and the latest updated SE)! That is, games there under WINDOWS on the enable EMS tab are not available. The "1MB" card there, of course, does not look very good under WINDOWS (Although it is better than in some other virtual machines) - literally one small continuous window of 64KB in size, the rest is all smeared I don't understand how. But to load this frame, you probably need a little more (According to my estimates, really, from 72 to 96 KB). So, Windows ME under the same identical conditions manages to load the "Page Frame" into the same small window without any problems and does it quite correctly (Although the "1MB" card itself is almost identical). So, it turns out that in Windows ME this mechanism was really somewhat improved? If so, can this improvement be ported to Windows 98 somehow as well? Or does this idea not make much sense?

LocalLoadHigh=1 is generally initially spelled out. But by itself, it does not affect anything. Apparently, it needs something else to work correctly, the same UMBPCI, for example (But, I hope, not slow EMM386.EXE?). I'm trying to figure out what is missing at the minimum. After all, there is still about 64KB in any case should remain free to support EMS under WINDOWS (Without it, the game simply does not start). I'm also trying to find some substitute for EMS, which would preferably eat 32KB or less (Or even work somehow differently, but could transfer control to WINDOWS).

Given "XMS2EMS.SYS", at least, works correctly on my hardware (Unlike 386MAX, which causes a hang when booting). However, this is at the DOS stage. But when you start WINDOWS, at the very final stage, right before the desktop appears, the following message appears on a black background: and then the computer shuts itself down. After a bit of searching on the Internet, I was able to find out that this problem may be caused by the lack of "XMS2EMS.SYS" support for the Global EMM Import Specification (GEMMIS), which is required for transferring control to WINDOWS. Here, for example, something similar is discussed (About the need to add this function to a similar product): https://github.com/Baron-von-Riedesel/Jemm/issues/5 it also provides links to GEMMIS source code sources and examples of open source products where it has already been successfully implemented (for example, DOSBOX). As part of the package " xms2ems.zip "contains its source code in the file "xms2ems.asm". You can download it, for example, here: https://www.minuszerodegrees.net/5170/ram/5170_extended_memory_use.htm or here: http://files.mpoli.fi/unpacked/software/programm/asm/dosutil.zip/ Do you think it will be possible to add support for GEMMIS to XMS2EMS so that you can boot with it on WINDOWS?

I suspect that this hardware is eating up so much space (video card, first of all). By the fact that under normal conditions, for example, it should be something like this: in this case, I would be able to simultaneously place EMS and HIMEM in the upper memory... Well, in general, okay, the option with different configurations (Game\Working), I quite like it too. Moreover, so far only one such game has come across, for which a rollback was needed IO.SYS, and all the others work. In other words, the situation is quite rare, exceptional, and potentially solvable. If there are no simple obvious paths or updates for IO.SYS, in principle, and so it will do. Thank you all.

Also, on a tip from MERCURY127, I started digging to the side HIMEM.SYS and I found another solution like this: https://www.mdgx.com/umb.htm#HIR And with it, it really turns out to free up quite a lot of memory and memory. IO.SYS from TBPPlus3 becomes less pronounced: but now there is not enough "EMS" memory. As it turned out, this HIRAM+UMBPCI eats up exactly the same area the amount of memory that WINDOWS normally allocated to maintain EMS. Here it is (Marked "PP"): and after applying HIRAM+UMBPCI, this area is already dealing with them: Accordingly, Windows cannot find the required space (a contiguous free chunk). So EMS it becomes no longer available and the game starts swearing again (and of course it doesn't work). I don't succeed place both at the same time..

Thank you for your answer, but what can actually be done in this situation? Rudolph's Readme doesn't say much about it a lot has been written: Yes, so far we have to survive just like that. When I roll back IO.SYS up to version 1.3 the game works no complaints. I haven't ventured to work with large disks with this legacy IO yet... This is the configuration purely temporary and only for running this one problematic game. For normal operation, I return IO.SYS version 3.0 is back in place. It's not very convenient, but at least it works.

Hi. I started the game and it ran out of memory. After looking at what the memory is occupied with, I found that HIMEM.SYS eats up 46KB, while on a clean system (On a virtual machine) about 1KB. I went to look at the difference and found that the culprit of the problem is IO.SYS. As it turned out, this one IO.SYS from the TERABYTE PLUS PACKAGE version 3.0. I have this version 3.0 package installed for a very long time to support large disks and it works otherwise quite stable all this time. I checked previous versions of TERABYTE PLUS PACKAGE and it turned out like this: IO.SYS from TERABYTE PLUS PACKAGE versions 1.0 to 1.3 (Inclusive). IO.SYS from TERABYTE PLUS PACKAGE versions 2.0 to 3.0 (Inclusive). What do you recommend to do in this case? I see a very impressive list of changes there. Can I roll it back IO.SYS before version 1.3? Or are there any other ways to solve the problem? Thank you.

Everything would be fine, but for some reason it constantly loads the processor and periodically accesses the disk: This is rather questionable behavior. Is it possible to use the MultiCore9x SDK to allow the guest OS to manage all CPU cores except the first one (and at the same time redirect all 64-bit memory above 4GB there)? And are there any guest add-ons for this VM at all (Seamless transition, shared folders, dragging files back and forth)? But this module "KQEMU" seems to still not work for me here. I can't even imagine what he still lacks for a full-fledged job.

Greetings. Please tell me how to make sure that the "KQEMU" module has actually started and is functioning correctly? I try the standard WINDOWS command "net start kqemu" under Windows 98 and it returns that " Error 2185: The service name is invalid. Make sure you are specifying a valid service name, and then try again.". In the QemuManager menu, the "Uninstall KQEMU Accelerator" item remains INACTIVE after installing this module (In XP, it becomes active). I also selected "KQEMU-Full Acceleration" in the settings. But I still don't feel any difference in the speed of the guest OS. It feels like it's not working... Maybe I didn't take something into account or do something wrong? Do you have this module running on Windows 98?

Do you mind if I try to answer this question? I don't really understand it, but... Here are two versions Kernel32.DLL: kernel32_BAD.dll (5.1.2600.2945 (xpsp. 060704-2357)) - the browser crashes with it (On Mega.nz). kernel32_GOOD.dll (5.1.2600.3119 (xpsp_sp2_qfe. 070416-1259)) - it already works fine with it. Comparing the two versions using CFF Explorer showed that in my opinion, there is only one significant difference between them. Only one parameter was added to "Export Directory" : 00000171 00060F58 0170 00006704 GetLogicalProcessorInformation In other places, nothing seems to have changed significantly.

Thank you. It is stored in the same place (in Kernel32.dll)? (Yes, these parameters follow right behind...). You can already make an "RDVDRIVE" and it works! It remains to find and replace "DV" with "AM" in the code, which already looks easy to solve (Although it is no longer critical or significant, because the main goals have been achieved). At the same time, I checked it in WinME and no, alas, both do not work. It seems that since WinME, they have removed this from the code altogether. Although the same "MS-RAMDRIVE" in the body Kernel32.dll for some reason, it is still present. Although I haven't tried with installed service packs. Well, only PSE36 ramdisk for NT4 comes to mind here. I tried to find it in order to test it under XP, but it turned out to be a difficult task. This SDK seems to have been completely lost to history. There is only some information left that such a principle once existed, but the sources themselves can no longer be downloaded: http://web.archive.org/web/19990421095003/http://developer.intel.com/vtune/vtcd/index.htm http://web.archive.org/web/19991007020425/http://developer.intel.com/vtune/pse36/ http://web.archive.org/web/19991008040955/http://support.intel.com/support/performancetools/pse36/sysreq2.HTM If you find this ramdisk and it will work in XP, then you can do something else. Create a disk in XP and then initialize it in 98 using RAMDRV4M, which already provides this feature. You don't need anything extra to do this. Or, which is more correct, but will require some improvements - to upgrade the ramdisk for NT already, giving it similar functionality (This driver was distributed with the source texts, so by combining it with the RAMDRV4M code, this might have been possible). Yes, everything worked out - icons and types changed everywhere: At the same time, after RAM\RDV, you can add any valid characters, in any language, but only so that their total number does not exceed 11. Thus, if you change " RDV " to "PAM", you even get a certain localized construction - "PAMДИСК" => "".

And another question - is it possible to get access to the ramdisk ALREADY placed in memory under WinXP? During the XP session, after 98, the information is securely stored there and does not disappear when you return to 98 (I checked). Question - is it possible to reach it directly under WinXP (Read\Write)?

Yes, I already tried this, but it didn't work. You tried it and it worked (By the way, this applies to any disk under 98\98SE, but it doesn't work at all in WinME. Just in case I'm doing something wrong)? The options I've already checked are "RAMDRIVE[Three spaces]", "RAMDRIVE[HEX: 00 00 00]", "RAMDRIVE[HEX: FF FF FF]". In the first case, Windows cuts off the last three spaces. It doesn't matter if you do this via the command line ("LABEL M: RAMDRIVE ") or via the disk properties - the result is the same: just "RAMDRIVE" remains and nothing changes. With the second two options, the result is identical (Nothing changes: the disk type and icon remain the same, corresponding to the local disk, but not ramdisk).

I was able to find out that "MS-RAMDRIVE" is located in "KERNEL32.DLL". I just changed it to "MS-ROMDRIVE", replacing one letter ("A" with "O") and it worked! In other words, the name is mapped exactly from there. The question now is, is there any way to cut off "MS-" painlessly so that it doesn't affect everything else? Simply deleting these three characters is not an option - the code will shift and the OS will not boot. Is it obvious that some other approach is needed here, or does this issue not have a simple solution?

SweetLow, hi, do you know where Windows gets the ramdisk mapping from to the disk name "MS-RAMDRIVE"? With a different name, as shown in the screenshots above, the disk is defined as "Type: Local Disk" and assigned an icon corresponding to the local disk. If you enter the name "MS-RAMDRIVE", the icon changes to microchip and the type changes to "Type: RAM Disk". When it is RAM Disk in "My Computer" it is easy to immediately distinguish it by another icon. And so (By default), it merges with other (Regular) disks, without being distinguished in any way. It would be possible to leave the name "MS-RAMDRIVE", but as I wrote earlier, it is too long and does not fit completely. I would like to make the name "RAMDRIVE" by default and that it would be defined by the system as "MS-RAMDRIVE", assigning it the correct type and icon.