Kahenraz

I have been unable to find a vcache setting that mitigates this issue. It also shouldn't be a problem when I use a compatible memory size, such as 256MB.

The problem exists identically with both with Cygwin 1.5.25 XWin as well as Xming 6.9.0.31, but Xming runs on top of Cygwin, so this isn't indicative of much. Which version of Xming are you using that requires KernelEx?

I'm experimenting with Windows 98 and ME on a very fast system (Core 2 Duo) where I can test a variety of hardware combinations. But the most problematic issue I'm having is the operating system running out of some kind of memory somewhere. One of the areas I am experimenting with is X forwarding over SSH to expand the suite of software available on such an old system to include anything and everything that could possibly run on a Linux system, such as modern browsers, development environments, etc. The problem I'm having is that, no matter how little or how much memory I throw at it, no matter how I configure it, the system keeps running out of some kind of memory, despite there being plenty of available resources during this event. The symptoms are my SSH tunnel failing and then being unable to open additional command prompts. Even if I close all running child processes (sometimes this is impossible), whatever memory is being allocated is not properly freed and I cannot reinitialize a Bash shell, XWin, or whatever, until I reboot the entire system. I suspect that this is somehow related to the SSH client running from within a DOS window, and that the resources being consumed are related to the 16-bit subsystem and not Win32 protected mode. I have tried monitoring the system resources using Sysinternals Process Explorer and Windows's own System Monitor, but it's difficult to track exactly WHERE the memory is going and WHAT process is using it, as I can't find any way to display how much any individual process has allocated. At best, I can view how memory is being used across the entire system and the swap file, but there is never a significant uptick in memory to suggest a leak, and there is always free memory and swap available at the time of these memory pressure events. How can I debug this memory issue by monitoring memory allocations for specific processes, what memory exactly is running out, and why isn't it being reclaimed upon program termination? I have tried using a single 256MB stick of memory and up to 2GB of memory (with R. Loew's patch). I also tried limiting vcache in system.ini to various values such as 512MB and 64MB; the system does reflect this value, but it does not mitigate the problem. I have found many references to this specific memory error as being related to vcache, but I can't confirm that the problem being discussed is related to my issue. Using 256MB of physical memory or artificially limiting the vcache setting does not seem to make a difference. What I am looking for is help on how to further investigate this issue. I am a software programmer with extensive historical Win32 experience, but primarily on Windows NT based operating systems. I'm unfamiliar on how to properly debug Windows 9x based software that is misbehaving, and I'm finding that I am otherwise unprepared for these kinds of errors that just don't exist on NT.

One of the issues I have with Windows 9x/ME is that there is no convenient way to manage drive letters, and it's not unusual for them to get moved around when attaching an additional device. There is a tool called Letter Assigner by Vadim Burtyansky which fixes this issue and allows drive letters to be changed and made consistent. I was surprised today to find that when I tried this tool on Windows ME, the system became unbootable. Further investigation showed that the issue was some kind of incompatibility with the WinME/DOS patch. Restoring the original IO.SYS fixed the problem where the system failed to boot, but this also sacrificed the ability to boot into DOS. I can't figure out what this tool is doing, and there is no information about what behavior is used to make it function anywhere in the documentation. Does anyone know what this tool is doing and why it is incompatible with the WinME/DOS patch? See here for some additional information on my problem and triage: https://www.vogons.org/viewtopic.php?p=1086922#p1086922

I can confirm that a PIF from Windows 98 does bypass the warning. It does appear that Windows ME retains this functionality and that the problem is limited to the file properties dialog.

Hi. I can't find links to any of these service packs. Where are they?

I found this file in the Unofficial Windows 98SE SP3. It has a lower build number than the notepad.exe that is included with Windows ME (4.90.0.3000), but has later the features, such as Ctrl+A to select all, as well as other accelerators such as Ctrl+S to save. Where I this version of notepad.exe from and why does it have more features than the one included with Windows ME?

I found that the Unofficial Service Pack for Windows 98SE came with cmd.exe version 5.0.2144.1, which appears to be from Windows 2000. I seems to work fine with basic testing, but when I try to use CD or PUSHD to change directory from a root directory (C:\, D:\, etc) I get a message "Access is denied". If I am instead already in a child directory, such as C:\Windows, then I can successfully change directory to C:\Windows\Desktop. I am testing this on Windows ME and I have this error with or without KernelEx installed. Is there a way to work around this? I would like to have the NT command interpreter available in Windows 9x to run more complex batch scripts that need to change directories.

Confirmed that this is still a problem with VMware Workstation 16 Pro version 16.2.1. My CPU is a Ryzen 7 1800X with the latest update for my BIOS and Windows 11 host. I know this doesn't help, but it's another point of reference.

If the behavior still exists in the PIF file and it not blocked by the operating system, would it possible to either patch or swap the resource from Windows 98 into ME to restore the old dialog?

This is not an issue with all DOS games, only some. And it's the behavior of the OS that is deciding what is best for performance when in reality my hardware is more than capable. 1. The wizard cannot create a shortcut that is capable of avoiding this dialog in Windows ME. 2. There are no options exposed in Windows ME that are "better" -- note that there are LESS options than Windows 98, where this dialog COULD be avoided. 3. The problem isn't clicking buttons but the process and delay of the window changing focus and minimizing, the annoying dialog popup, dismissing and then reestablishing focus. The entire screen, program, and desktop will blink and it's very unpleasant, laggy, and would confusing for guests, even if it were automated. 4. This is running on native hardware. The program is not challenging and there is no VM. The problem is the missing option since Windows 98 where this dialog could be suppressed.

Windows 95 and 98 have a tick box to uncheck "Suggest MS-DOS mode as necessary" in the Advanced properties of DOS programs, but this option does not appear in Windows ME. Without it, Windows suspends some DOS applications when they are run with this annoying popup. There is a delay when dropping back to Windows, having to close the dialog, then select the window and set it back to full screen. This is particularly tedious if I have both hands on the keyboard as dismissing the dialog and selecting the Window is best done with the mouse. Is there any way to restore this functionality to stop the dialog from appearing? I happen to like the additional features that Windows ME provides over Windows 98, and would prefer to use it instead. The limiting factor is that I also want to run a lot of DOS programs, and this popup is infuriatingly annoying. This is a follow-up on a topic with the same title that I made on the VOGONS forum: https://www.vogons.org/viewtopic.php?f=46&t=86873

Hi. This is still a problem. Has this been fixed?

Can you please add an option to remove the command bar? I don't use this feature and it would further reclaim space in the file explorer.

The command bar blinks when navigating between paths.

You're asking for $3,000 for a license that doesn't require activation? That's a business license. I'm a home user. Can you please clarify? It sounds like it is only possible to rent this software as a home user. Or buy an offline license if you are wealthy.

Would you please offer a provide an option for purchase unlimited use without online activation? I don't like buying software which requires an online subscription to activation and would pay more for this. I would like to buy this software but the only option is to rent it.

The issue appears to be related to attempting to integrate Desktop Protocol 8.1 and its associated prerequisites and updates. The KBs are: Windows6.1-KB2574819-v2-x64.msuWindows6.1-KB2857650-x64.msuWindows6.1-KB2592687-x64.msuWindows6.1-KB2830477-x64.msuWindows6.1-KB2913751-x64.msuWindows6.1-KB2923545-x64.msuWindows6.1-KB2984976-x64.msuWindows6.1-KB3005781-x64.msu

While trying to filter through what I do have, is there a way that I can determine if a particular hotfix already exists in a rollup I've already installed?

While working on building an updated Windows 7 SP1 disc, I found a bunch of hotfixes I had which weren't part of my slipstream but were also not missing as an update while querying Windows Update post-install. http://pastebin.com/cD6CKhH7 Does this mean that all of these updates have been included elsewhere in a rollup I've already installed?

I added a program to install silently with WinToolkit but entered the wrong parameters. I can see the installers on the DVD in /WinToolkit_Apps, but running a grep across the entire disc does not locate any file containing the install parameters. There is a file /sources/install.ini which seems like the right place but it's not in there.

While narrowing this down and installing updates slowly, the problem was avoided. Adding all of the updates at once to a clean SP1 disc still causes this issue.

Yes, that's what I'm doing.

Still trying to narrow this down. The problem seems to be one of these: Windows6.1-KB2524840-x64.msuWindows6.1-KB2525835-x64.msuWindows6.1-KB2526629-v3-x64.msuWindows6.1-KB2529781-x64.msuWindows6.1-KB2529825-x64.msuWindows6.1-KB2533552-x64.msuWindows6.1-KB2533623-x64.msuWindows6.1-KB2535094-x64.msuWindows6.1-KB2535158-x64.msuWindows6.1-KB2537203-x64.msuWindows6.1-KB2538047-x64.msuWindows6.1-KB2539513-x64.msuWindows6.1-KB2545561-x64.msuWindows6.1-KB2545698-x64.msuWindows6.1-KB2545735-x64.msuWindows6.1-KB2546868-x64.msuWindows6.1-KB2547666-x64.msuWindows6.1-KB2549067-v2-x64.msuWindows6.1-KB2549079-x64.msuWindows6.1-KB2550648-v2-x64.msuWindows6.1-KB2551090-v2-x64.msuWindows6.1-KB2551687-x64.msuWindows6.1-KB2554231-x64.msuWindows6.1-KB2554859-x64.msuWindows6.1-KB2554876-v2-x64.msuWindows6.1-KB2555189-x64.msuWindows6.1-KB2555392-x64.msuWindows6.1-KB2555948-x64.msuWindows6.1-KB2559392-x64.msuWindows6.1-KB2560289-x64.msuWindows6.1-KB2560656-x64.msuWindows6.1-KB2564958-x64.msuWindows6.1-KB2566314-x64.msuWindows6.1-KB2570947-x64.msuWindows6.1-KB2574819-v2-x64.msuWindows6.1-KB2575866-x64.msuWindows6.1-KB2575928-x64.msuWindows6.1-KB2577968-x64.msuWindows6.1-KB2578214-x64.msuWindows6.1-KB2579686-x64.msuWindows6.1-KB2581608-x64.msuWindows6.1-KB2581690-x64.msuWindows6.1-KB2582679-x64.msuWindows6.1-KB2584475-x64.msuWindows6.1-KB2584577-x64.msuWindows6.1-KB2589154-x64.msuWindows6.1-KB2591271-v2-x64.msuWindows6.1-KB2591500-v3-x64.msuWindows6.1-KB2591857-x64.msuWindows6.1-KB2592687-x64.msuWindows6.1-KB2594586-x64.msuWindows6.1-KB2598845-x64.msuWindows6.1-KB2600100-x64.msuWindows6.1-KB2603203-x64.msuWindows6.1-KB2603229-x64.msuWindows6.1-KB2604115-x64.msuWindows6.1-KB2607047-x64.msuWindows6.1-KB2614892-x64.msuWindows6.1-KB2615327-x64.msuWindows6.1-KB2616386-x64.msuWindows6.1-KB2616879-x64.msuWindows6.1-KB2618301-x64.msuWindows6.1-KB2618535-x64.msuWindows6.1-KB2618640-x64.msuWindows6.1-KB2618752-x64.msuWindows6.1-KB2619082-x64.msuWindows6.1-KB2619260-v2-x64.msu

I am attempting to build an updated ISO of Windows 7 SP1 x64. I am using the "Windows 7 Professional SP1 Media Refesh x64" iso as a base with the following updates slipstreamed with WinToolkit 1.5.3.5: http://pastebin.com/raw.php?i=ZUZ4gdeD These updates were obtained through Alphawaves' Downloader which is built into WinToolkit. Upon installation on a VMWare image, I receive the following error: I only receive this error after building a slipstreamed disc. I would attempt to narrow down which update is causing the problem but considering it takes over three hours to integrate all of these updates, is very challenging. Can anyone provide some insight on this?