All right guys, anyone able to make some patch (free or commercial) to transform those 16bit GDI and User segments into significantly bigger segments so that it is possible to run really many apps at once ?
Dencorso, if you happen to read this, could you please upload the pdf you made of the older thread that got deleted by mistake a year ago or so, if you still have it ?
For the life of me I can't find it anymore on my HDs and I think it would be nice if it could be uploaded because there is quite a good deal of serious discussion about the topic in it if I recall correctly.
Full Version: The 16bit heaps expander thread
MSFN Forums > Microsoft Software Products - Discussion & Support > Windows 95/98/98SE/ME > Windows 9x Member Projects
QUOTE (eidenk @ Oct 01 2007, 03:18 AM)
My bottleneck when using Windows ME are the resources.
I have nearly 2GB of RAM. I can run scores of processes at once without stabilty issues. All this works very
well just only sometimes I am stuck for lack of resources because I open too many apps at once or too
many plugins in certain audio applications I use.
So that I am after a patch that could significantly increase the size of the 32bit segments of the resources.
I have nearly 2GB of RAM. I can run scores of processes at once without stabilty issues. All this works very
well just only sometimes I am stuck for lack of resources because I open too many apps at once or too
many plugins in certain audio applications I use.
So that I am after a patch that could significantly increase the size of the 32bit segments of the resources.
QUOTE (dencorso @ Oct 12 2007, 01:04 AM)
I agree with eidenk: the resources problem (running too low on them too fast) is IMHO the major limitation
faced by us users of Win 9x/ME, and sure is worth looking at more closely. AFAIK, they are implemented
respectively in GDI.EXE/GDI32.DLL and USER.EXE/USER32.DLL. Some useful info about them is available
in now classic "Windows 95 System Programming Secrets" by Matt Pietrek.
faced by us users of Win 9x/ME, and sure is worth looking at more closely. AFAIK, they are implemented
respectively in GDI.EXE/GDI32.DLL and USER.EXE/USER32.DLL. Some useful info about them is available
in now classic "Windows 95 System Programming Secrets" by Matt Pietrek.
QUOTE (galahs @ Oct 12 2007, 08:50 AM)
More information of Win9x system resources and its limitations here:
http://www.helpwithwindows.com/techfiles/win-resources.html
and below:
http://www.helpwithwindows.com/techfiles/win-resources.html
and below:
QUOTE (Al Fasoldt @ Apr 15 2001)
Why the memory problem in Windows 95, 98 and Me isn't fixable
Copyright © 2001, Al Fasoldt
Copyright © 2001, The Syracuse Newspapers
The standard versions of Windows have a big problem handling memory. This is hardly news to most of
us who use Windows, but there's a hidden side to the problem that makes it worse than it might seem.
Even people who are otherwise knowledgeable about Windows miss the significance of the problem. The
basic flaw is bad enough -- Windows has only a tiny area of memory to keep track of what's going on --
but the hidden aspect is that the problem can't be fixed.
Crazy as it seems, this fatal flaw in Windows 95, Windows 98 and Windows Me is never going to go
away. No software utility can fix it. Neither MemTurbo nor RAM Idle, two of the most popular programs
that claim to fix Windows memory handling, do anything to fix the problem. Nothing will.
Keep that in mind the next time you see claims about programs that supposedly fix problems with
Windows. A software program can't fix this Windows memory flaw any more than a set of racing tires can
turn a Hyundai into a Ferrari. The design of Windows makes a fix impossible. Only a complete redesign of
Windows 95, Windows 98 and Windows Me would work -- and, in fact, that's what Microsoft is doing for
the next home version of Windows, which it plans to introduce later this year. That version is Windows XP.
Windows 95, Windows 98 and Windows Me are like big cars fitted with tiny gas tanks. They will run fine
for a while and then sputter to a stop when they use up their allotment of memory.
The memory I'm referring to isn't the standard kind of memory that all computers need to function properly. It's a special area of memory unique to Windows. It's called "resource" memory, where Windows
keeps its pointers to what's going on.
When that memory area gets full, Windows loses control. Your mouse might stoop responding or you'll find
that you can't close a window on your screen. You'll be stymied just trying to close programs, and your
Windows PC will freeze. You'll lose what you were working on.
Ready for the wacko part of this? This storage area is so small, so improbably tiny, that it's not even
expressed in megabytes. Your PC's hard drive probably has hundreds and hundreds of megabytes of
storage. (A megabyte is 1 million bytes, and a byte is the smallest unit of storage.) If it's a modern
computer, your PC's actual memory probably reaches all the way to 64 megabytes or more.
It sure would be great if Windows knew what to do with 64 megabytes for its resources. But let's not be so
greedy. It would be just fine if it knew how to deal with 32 megabytes. Or with 16 megabytes. Heck, I'd
settle for 8 megs. Or even 1.
But even 1 megabyte is out of the reach of Windows when it's dealing with resources. Want to hear the
really bad news about this resource memory? Windows 95, Windows 98 and Windows Me can't set aside
any more than 64 kilobytes for this vital storage. No matter how much memory your PC has -- and most
new ones have at least 64 megabytes of memory -- all that Windows can use for resources is 64 kilobytes
(usually called "64K").
This means Windows can only use one-tenth of 1 percent of the typical memory in a modern PC for the allimportant
function of keeping track of what's going on.
This is the bad news that seems to follow Windows users around like a toothache. I get dozens of letters a
week from Windows users looking for ways to keep their Windows 95, Windows 98 or Windows Me
computers from running out of memory and crashing. They often ask if memory-enhancing programs they
see on the Internet actually fix the problem.
The answer is no. The 64K limit in Windows 95, 98 and Me is a barrier that can't be taken down. No
program can change this. Adding more regular memory (adding RAM, in other words) won't fix it, either.
Rebooting (shutting down and starting up again) can help by clearing out resource memory. When resource
memory runs low again, reboot again.
Apart from rebooting, which hardly counts as a "fix," there is no way to cure this flaw in these versions of
Windows. If you want to run a version of Windows that handles memory properly, you have two current
choices -- Windows NT, an older version that is about to be retired, or Windows 2000, a new version I've
raved about in print and on TV. Or you can wait for Windows XP later this year.
With the introduction of Windows XP, which, because of Microsoft's nearly total monopoly on PC operating
systems, will show up on practically every new PC sold by the end of the year, Microsoft will at last be
making an advertised version of Windows that is reliable and able to keep running for weeks without the
need for rebooting. If you're not drawn to the Mac or to Linux through your frustrations with Windows 95,
Windows 98 and Windows Me, and if you're scared away by Microsoft's refusal to tell you that Windows
2000 actually exists, you will want to upgrade to Windows XP as quickly as possible.
Copyright © 2001, Al Fasoldt
Copyright © 2001, The Syracuse Newspapers
The standard versions of Windows have a big problem handling memory. This is hardly news to most of
us who use Windows, but there's a hidden side to the problem that makes it worse than it might seem.
Even people who are otherwise knowledgeable about Windows miss the significance of the problem. The
basic flaw is bad enough -- Windows has only a tiny area of memory to keep track of what's going on --
but the hidden aspect is that the problem can't be fixed.
Crazy as it seems, this fatal flaw in Windows 95, Windows 98 and Windows Me is never going to go
away. No software utility can fix it. Neither MemTurbo nor RAM Idle, two of the most popular programs
that claim to fix Windows memory handling, do anything to fix the problem. Nothing will.
Keep that in mind the next time you see claims about programs that supposedly fix problems with
Windows. A software program can't fix this Windows memory flaw any more than a set of racing tires can
turn a Hyundai into a Ferrari. The design of Windows makes a fix impossible. Only a complete redesign of
Windows 95, Windows 98 and Windows Me would work -- and, in fact, that's what Microsoft is doing for
the next home version of Windows, which it plans to introduce later this year. That version is Windows XP.
Windows 95, Windows 98 and Windows Me are like big cars fitted with tiny gas tanks. They will run fine
for a while and then sputter to a stop when they use up their allotment of memory.
The memory I'm referring to isn't the standard kind of memory that all computers need to function properly. It's a special area of memory unique to Windows. It's called "resource" memory, where Windows
keeps its pointers to what's going on.
When that memory area gets full, Windows loses control. Your mouse might stoop responding or you'll find
that you can't close a window on your screen. You'll be stymied just trying to close programs, and your
Windows PC will freeze. You'll lose what you were working on.
Ready for the wacko part of this? This storage area is so small, so improbably tiny, that it's not even
expressed in megabytes. Your PC's hard drive probably has hundreds and hundreds of megabytes of
storage. (A megabyte is 1 million bytes, and a byte is the smallest unit of storage.) If it's a modern
computer, your PC's actual memory probably reaches all the way to 64 megabytes or more.
It sure would be great if Windows knew what to do with 64 megabytes for its resources. But let's not be so
greedy. It would be just fine if it knew how to deal with 32 megabytes. Or with 16 megabytes. Heck, I'd
settle for 8 megs. Or even 1.
But even 1 megabyte is out of the reach of Windows when it's dealing with resources. Want to hear the
really bad news about this resource memory? Windows 95, Windows 98 and Windows Me can't set aside
any more than 64 kilobytes for this vital storage. No matter how much memory your PC has -- and most
new ones have at least 64 megabytes of memory -- all that Windows can use for resources is 64 kilobytes
(usually called "64K").
This means Windows can only use one-tenth of 1 percent of the typical memory in a modern PC for the allimportant
function of keeping track of what's going on.
This is the bad news that seems to follow Windows users around like a toothache. I get dozens of letters a
week from Windows users looking for ways to keep their Windows 95, Windows 98 or Windows Me
computers from running out of memory and crashing. They often ask if memory-enhancing programs they
see on the Internet actually fix the problem.
The answer is no. The 64K limit in Windows 95, 98 and Me is a barrier that can't be taken down. No
program can change this. Adding more regular memory (adding RAM, in other words) won't fix it, either.
Rebooting (shutting down and starting up again) can help by clearing out resource memory. When resource
memory runs low again, reboot again.
Apart from rebooting, which hardly counts as a "fix," there is no way to cure this flaw in these versions of
Windows. If you want to run a version of Windows that handles memory properly, you have two current
choices -- Windows NT, an older version that is about to be retired, or Windows 2000, a new version I've
raved about in print and on TV. Or you can wait for Windows XP later this year.
With the introduction of Windows XP, which, because of Microsoft's nearly total monopoly on PC operating
systems, will show up on practically every new PC sold by the end of the year, Microsoft will at last be
making an advertised version of Windows that is reliable and able to keep running for weeks without the
need for rebooting. If you're not drawn to the Mac or to Linux through your frustrations with Windows 95,
Windows 98 and Windows Me, and if you're scared away by Microsoft's refusal to tell you that Windows
2000 actually exists, you will want to upgrade to Windows XP as quickly as possible.
QUOTE (fastlanephil @ Oct 14 2007, 02:16 PM)
galahs, dencorso, eidenk, rloew
From what I understand of the problem, in order to make Win 95-98-ME able to run (backward compatible with)
16-bit Win 3.X programs, they need to be able to operate in 16-bit mode. Thus the files, User.exe, User32.dll,
GDI.exe, and GDI32.dll limit the 16-bit system resource size to 64 kbyte. Likewise, there are three 32-bit system
resource limitations, 2 Mbyte each per this article (click "About System Resources" at the bottom):
http://www.mvps.org/serenitymacros/repair.html
Some more reading on the subject:
http://www.aumha.org/win4/a/resource.htm
From what I understand of the problem, in order to make Win 95-98-ME able to run (backward compatible with)
16-bit Win 3.X programs, they need to be able to operate in 16-bit mode. Thus the files, User.exe, User32.dll,
GDI.exe, and GDI32.dll limit the 16-bit system resource size to 64 kbyte. Likewise, there are three 32-bit system
resource limitations, 2 Mbyte each per this article (click "About System Resources" at the bottom):
http://www.mvps.org/serenitymacros/repair.html
Some more reading on the subject:
http://www.aumha.org/win4/a/resource.htm
QUOTE (rloew @ Oct 15 2007, 10:39 PM)
After reviewing the various documents and web sites relating to "resources", I have come to the following conclusions:
The two 16-Bit 64K Resources are the most serious limitation, but are probably not expandable without
breaking many programs. I suspect that 16-Bit pointers may be used by various programs, all of which would
need to be fixed. Tracking down all of the programs that would need to be patched could be very tedious, and
doing so for third-party programs would be prohibitive.
The three 32-Bit 2MB Resources probably can be expanded more easily as long as the programs that use it
are not hard coded to expect 2MB. All of the references, that I have read, insist that these resources do not get
depleted in any reasonable use. I am not sure how useful expanding them would be.
I have as yet to locate the actual owner of these resources, but I currently suspect KERNEL32.DLL maintains
them.
The two 16-Bit 64K Resources are the most serious limitation, but are probably not expandable without
breaking many programs. I suspect that 16-Bit pointers may be used by various programs, all of which would
need to be fixed. Tracking down all of the programs that would need to be patched could be very tedious, and
doing so for third-party programs would be prohibitive.
The three 32-Bit 2MB Resources probably can be expanded more easily as long as the programs that use it
are not hard coded to expect 2MB. All of the references, that I have read, insist that these resources do not get
depleted in any reasonable use. I am not sure how useful expanding them would be.
I have as yet to locate the actual owner of these resources, but I currently suspect KERNEL32.DLL maintains
them.
QUOTE (dencorso @ Oct 15 2007, 11:34 PM)
Yes, they are THE question! What I had been thinking on, for a long time now, would be more of a workaround than a fix proper: I imagined a ring 0 program, say, srfix.vxd, that took a snapshot of the 16-bit USER stack, just after boot and saved it somewhere. Then, when the user resources get too low, the user closes all running programs, except those that were running just after boot and triggers a hotkey, causing srfix.vxd to restore the saved snapshot, thus releasing any orfaned resources lost due to leaks related causes. Ideally, the initial snapshot taking should be automatic, but as it's really not obvious in which order startup programs will load,perhaps that too would need to be an user triggered event. And srfix.vxd might do it independently also for GDI. I'm fully aware that this is not more than a very brute force workaround, but it may be a start. Please let me know what you think of this.
QUOTE (fastlanephil @ Oct 16 2007, 03:04 AM)
Thanks for the input everybody 
, I suppose that this is the real root of the system resource problem.
Note that in two bytes there are ((2 raised to the 8th power) squared =) 65536 possible combinations, thus there is only a 64K 16-bit heap size.
"...The resource table is essentially a big list of information about all the resources that are in memory at any
given time. So if an application tells Windows to load a resource, Windows finds an empty spot in this resource
table, and fills it in with the information about the resource that was just loaded. Now, instead of giving the
application a four-byte pointer to the resource, Windows can just tell the application where the resource is in
the table. If I tell Windows to load a window, and that window winds up taking the 383rd slot in the resource
table, Windows will tell me "Okay, I've loaded the resource, and it's #383." Since these 'index numbers' are
much smaller numbers than memory addresses, under this scheme, a resource's number can be stored in
only two bytes instead of four; when you only have a few megabytes of memory to work with, and lots of
resources being used, that's a huge improvement.
There's a problem with this scheme. There's only so many different possible values that you can store in a
certain number of bytes of computer memory, just like there's only so many different numbers you can write
down if you aren't allowed to use more than a certain number of digits. If you have four bytes of memory to
work with, you can store billions of different possible values in those four bytes. But if you only have two bytes,
there's only 65536 different numbers that you can store in those two bytes. So if you use two-byte numbers as
your resource identifiers, you can't have more than 65536 resources loaded into memory at one time; if you
loaded more than that, there'd be no way for programs to tell them apart. But on the computers of the day,
there'd be no way to fit more than a few thousand resources into memory at one time anyway. So this
limitation wasn't seen as being a problem, and the Windows designers went ahead and used the resource
table and two-byte resource identifiers.
Now, we leap ahead to the present day. Memory is incredibly cheap; the memory savings from using two-byte
resource numbers instead of four-byte pointers simply aren't significant anymore. There'd be more than
enough memory to hold hundreds of thousands of resources in memory at one time. But there's still only
65,536 different possible resource identifiers; so only that many resources can be loaded into memory at once.
Beyond that, you're out of resources, no matter how much memory you have left."
http://www2.whidbey.com/djdenham/Window_memory.htm
, I suppose that this is the real root of the system resource problem. Note that in two bytes there are ((2 raised to the 8th power) squared =) 65536 possible combinations, thus there is only a 64K 16-bit heap size.
"...The resource table is essentially a big list of information about all the resources that are in memory at any
given time. So if an application tells Windows to load a resource, Windows finds an empty spot in this resource
table, and fills it in with the information about the resource that was just loaded. Now, instead of giving the
application a four-byte pointer to the resource, Windows can just tell the application where the resource is in
the table. If I tell Windows to load a window, and that window winds up taking the 383rd slot in the resource
table, Windows will tell me "Okay, I've loaded the resource, and it's #383." Since these 'index numbers' are
much smaller numbers than memory addresses, under this scheme, a resource's number can be stored in
only two bytes instead of four; when you only have a few megabytes of memory to work with, and lots of
resources being used, that's a huge improvement.
There's a problem with this scheme. There's only so many different possible values that you can store in a
certain number of bytes of computer memory, just like there's only so many different numbers you can write
down if you aren't allowed to use more than a certain number of digits. If you have four bytes of memory to
work with, you can store billions of different possible values in those four bytes. But if you only have two bytes,
there's only 65536 different numbers that you can store in those two bytes. So if you use two-byte numbers as
your resource identifiers, you can't have more than 65536 resources loaded into memory at one time; if you
loaded more than that, there'd be no way for programs to tell them apart. But on the computers of the day,
there'd be no way to fit more than a few thousand resources into memory at one time anyway. So this
limitation wasn't seen as being a problem, and the Windows designers went ahead and used the resource
table and two-byte resource identifiers.
Now, we leap ahead to the present day. Memory is incredibly cheap; the memory savings from using two-byte
resource numbers instead of four-byte pointers simply aren't significant anymore. There'd be more than
enough memory to hold hundreds of thousands of resources in memory at one time. But there's still only
65,536 different possible resource identifiers; so only that many resources can be loaded into memory at once.
Beyond that, you're out of resources, no matter how much memory you have left."
http://www2.whidbey.com/djdenham/Window_memory.htm
QUOTE (rloew @ Oct 16 2007, 03:33 PM)
Dear Dencorso,
In addition to the issues you have already mentioned there are additional problems with this approach. I have
listed some of the more apparent ones below:
1. This approach does not help when you are in the middle of something and your resources run out. You
need to terminate everything before you can use
the Hotkey. You only avoid having to reboot, which would probably be a good idea by this time to clear out
other waste.
2. There is no guarantee that you can terminate ALL processes, or that some processes started after startup
must continue to run for proper operation afterwards.
3. When resources run out, the computer could be locked up. preventing you from using the Hotkey or
executing the srfix.vxd.
In addition to the issues you have already mentioned there are additional problems with this approach. I have
listed some of the more apparent ones below:
1. This approach does not help when you are in the middle of something and your resources run out. You
need to terminate everything before you can use
the Hotkey. You only avoid having to reboot, which would probably be a good idea by this time to clear out
other waste.
2. There is no guarantee that you can terminate ALL processes, or that some processes started after startup
must continue to run for proper operation afterwards.
3. When resources run out, the computer could be locked up. preventing you from using the Hotkey or
executing the srfix.vxd.
QUOTE (Drugwash @ Oct 17 2007, 07:41 AM)
As long as the resources discussion is still here, i'd like to come in with some thoughts, if I may. Please note
I'm no programmer so I may be talking nonsense, but hopefully some good idea could be hooked out of this.
Once the owner/maintainer of the resources is found, there could be added a hook that would maintain
multiple 16-bit heaps and a list of running applications, so when certain application requests a certain
resource, the hook could direct it to the correct heap.
Say 'application #5 requests resource #172' - the hook would know that the respective resource would be
found in heap #4, so it would redirect the request to the respective heap.
With multiple 16-bit heaps, I believe there would be no more resource problems. But what do I know... maybe
I'm far off. My apologies if so.
I'm no programmer so I may be talking nonsense, but hopefully some good idea could be hooked out of this.
Once the owner/maintainer of the resources is found, there could be added a hook that would maintain
multiple 16-bit heaps and a list of running applications, so when certain application requests a certain
resource, the hook could direct it to the correct heap.
Say 'application #5 requests resource #172' - the hook would know that the respective resource would be
found in heap #4, so it would redirect the request to the respective heap.
With multiple 16-bit heaps, I believe there would be no more resource problems. But what do I know... maybe
I'm far off. My apologies if so.
QUOTE (rloew @ Oct 18 2007, 02:29 AM)
Some Resources such as Windows can be accessed from more than one application so selecting Resource
heaps by application will not work.
A Resource indexing approach is a possibility I am considering. It will only work if all routines that use
Resource Handles to access Resource Data directly can be patched.
heaps by application will not work.
A Resource indexing approach is a possibility I am considering. It will only work if all routines that use
Resource Handles to access Resource Data directly can be patched.
Note: all posts between Oct 19 2007 and Nov 15 2007 did not refer to resources.
QUOTE (modicr @ Nov 16 2007, 03:29 AM)
Here is a nice article regarding Windows resources:
http://apptools.com/rants/resources.php
Under Windows 3.x, each of these two areas of memory was limited to 64K. All running applications shared that 64K for User resources and 64K for GDI. Needless to say, that created a huge bottleneck.
With the introduction of Windows 95 and continuing through Windows 98 and Windows Me, that 64K was increased dramatically and each of the two areas was further subdivided as follows:
- The 16-bit User heap (64K).
- The 32-bit User window heap (2MB).
- The 32-bit User menu heap (2MB).
- The 16-bit GDI heap (64K).
- The 32-bit GDI heap (2MB).
However, each one of these five memory sections is still fixed in size due to the Windows 9x/Me architecture, and cannot be increased, regardless of the amount of physical memory (RAM) installed on the machine. Modern applications demand more and more of the system. The more controls an application creates and the more files it opens, the more stress is placed on the operating system
Roman
http://apptools.com/rants/resources.php
QUOTE
Under Windows 3.x, each of these two areas of memory was limited to 64K. All running applications shared that 64K for User resources and 64K for GDI. Needless to say, that created a huge bottleneck.
With the introduction of Windows 95 and continuing through Windows 98 and Windows Me, that 64K was increased dramatically and each of the two areas was further subdivided as follows:
- The 16-bit User heap (64K).
- The 32-bit User window heap (2MB).
- The 32-bit User menu heap (2MB).
- The 16-bit GDI heap (64K).
- The 32-bit GDI heap (2MB).
However, each one of these five memory sections is still fixed in size due to the Windows 9x/Me architecture, and cannot be increased, regardless of the amount of physical memory (RAM) installed on the machine. Modern applications demand more and more of the system. The more controls an application creates and the more files it opens, the more stress is placed on the operating system
Roman
QUOTE (oscardog @ Nov 17 2007, 06:00 AM)
If of any help regarding patching user and gdi to overcome system resource limitations I notice that the GDT (global descriptor table) is used mainly for holding descriptor entries of operating system segments. In which the descriptor fields Base points to the starting location in the 4GB linear address space, D/B segment size bit, when the bit is set the processor assumes a 32bit segment (here perhaps allows the modifying of the 16bit heaps to 32bit) along with LIMIT segment limit (20 bits) which defines the size of the segment dependant upon Granularity bit being set or clear. The descriptor type bit and segment type should hopefully already be set as needed
If the 16 bit heaps are changed to 32 bit and allowed 2mb in seqment size the rest of the global descriptor table would then need its existing entries moved 2mb -64kb to accomadate this. Perhaps rebasing of some files will be required to conform to the new table
If the 16 bit heaps are changed to 32 bit and allowed 2mb in seqment size the rest of the global descriptor table would then need its existing entries moved 2mb -64kb to accomadate this. Perhaps rebasing of some files will be required to conform to the new table
QUOTE (dencorso @ Nov 18 2007, 12:52 AM)
Once upon a time, when Windows meant either Win 3.1 or Wfw 3.11, there was Helix Hurricane...
It had a "Heap Expander" that really did manage to expand the system's resources. It comprised two files: a 5.3KB VxD called HEAPX.386, and a 38.1KB NE driver, HEAPX.DRV... Helix got bought by McAfee (NAI, at that point) and never developed a Win 9x version for "Heap Expander", which was incompatible with Win 9x, because of the serious differences in implementation of GDI and USER heaps between Win 3.1 and Win 9x (described some posts above).
Be as it may, perhaps in-depth study of HEAPX.* might lend some interesting ideas on how to overcome the resources problem...
It had a "Heap Expander" that really did manage to expand the system's resources. It comprised two files: a 5.3KB VxD called HEAPX.386, and a 38.1KB NE driver, HEAPX.DRV... Helix got bought by McAfee (NAI, at that point) and never developed a Win 9x version for "Heap Expander", which was incompatible with Win 9x, because of the serious differences in implementation of GDI and USER heaps between Win 3.1 and Win 9x (described some posts above).
Be as it may, perhaps in-depth study of HEAPX.* might lend some interesting ideas on how to overcome the resources problem...
QUOTE (eidenk @ Nov 18 2007, 09:59 PM)
BTW, there is a tool for making sense of the resources percentages. It's called heap walker and it is part of Print99 on this page :
http://www.microsoft.com/downloads/details...;displaylang=en
A different version can be found here :
http://download.microsoft.com/download/pla...-us/newheap.exe
This might also be of interest :
http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/
I could not compile the programs successfully with VC6 but I am probably missing something. Haven't looked into it more than that.
http://www.microsoft.com/downloads/details...;displaylang=en
A different version can be found here :
http://download.microsoft.com/download/pla...-us/newheap.exe
This might also be of interest :
http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/
I could not compile the programs successfully with VC6 but I am probably missing something. Haven't looked into it more than that.
QUOTE (dencorso @ Nov 18 2007, 10:53 PM)
Thanks for the links, eidenk!
Let me add some more:
http://support.microsoft.com/kb/97759
and http://support.microsoft.com/kb/136776: Problems Using Helix Hurricane with Windows 95/98, where M$ sugests removing Hurricane altogether as a solution because... "Hurricane and its utilities are incompatible with Windows" 9x. Even so, it should be read.
Let me add some more:
http://support.microsoft.com/kb/97759
and http://support.microsoft.com/kb/136776: Problems Using Helix Hurricane with Windows 95/98, where M$ sugests removing Hurricane altogether as a solution because... "Hurricane and its utilities are incompatible with Windows" 9x. Even so, it should be read.
QUOTE (eidenk @ Nov 18 2007, 11:21 PM)
So you think there isn't a more recent version of heap expander than the one you posted ?
With heap walker I have been able to see that the percentages that appear on the system resource meter are a mesurement of the 16bit segments only apparently. The 32bit segment don't appear to be taken into account and as far as I have seen are barely used at all.
Another simple resource viewer :
http://www.geocities.com/the_real_sz/misc/bear_.htm
Those might also be of some interest :
http://www.japheth.de/Download/TaskList.ZIP
http://www.japheth.de/Download/WinInfo.ZIP
With heap walker I have been able to see that the percentages that appear on the system resource meter are a mesurement of the 16bit segments only apparently. The 32bit segment don't appear to be taken into account and as far as I have seen are barely used at all.
Another simple resource viewer :
http://www.geocities.com/the_real_sz/misc/bear_.htm
Those might also be of some interest :
http://www.japheth.de/Download/TaskList.ZIP
http://www.japheth.de/Download/WinInfo.ZIP
QUOTE (dencorso @ Nov 18 2007, 11:48 PM)
I think there is a very thin chance of a further version in Hurricane 2.03, but I do honestly doubt it. See: http://web.archive.org/web/19971212004348/...ne_updates.html. The file I posted came with Hurricane v. 2.02 (a.k.a. Helix Hurricane '95). There was a v. 2.03 (later a.k.a. McAfee Hurricane 98). I had moved on to Win 9x by then, and didn't care to get it, 'cause I knew they just didn't mix. Helix stopped development of Heap Expander in 1996, didn't port it to Win 95 and was sold in 97/98 to McAffe, that discontinued Hurricane altogether in 2000. That's all I know and my best guesses. I do miss HEAPX to this day.
PS: All our problem does lie with the 16-bit heaps. The 32-bit heaps are large enough. That's why I believe it should be possible to adapt/recreate HEAPX for 9x, to manage the 16-bit resources, letting the 32-bit resources alone: it's less than HEAPX needed to do under 3.1, not more...
PS: All our problem does lie with the 16-bit heaps. The 32-bit heaps are large enough. That's why I believe it should be possible to adapt/recreate HEAPX for 9x, to manage the 16-bit resources, letting the 32-bit resources alone: it's less than HEAPX needed to do under 3.1, not more...
QUOTE (eidenk @ Nov 19 2007, 12:10 AM)
You never did run it under 9x yourself then ? The MS KB you posted shows that it was intended to run under Win 95 and 98 doesnt'it ? It would be worth trying maybe.
As Hurricane and Nuts and Bolts 98 appear very similar in appearance, I've just had a look into the latter but no luck for a heapx or similar in there.
Seems like both products were from Helix originally who sold them to McAffee or something.
As Hurricane and Nuts and Bolts 98 appear very similar in appearance, I've just had a look into the latter but no luck for a heapx or similar in there.
Seems like both products were from Helix originally who sold them to McAffee or something.
QUOTE (dencorso @ Nov 19 2007, 12:33 AM)
Helix itself says "win 3.xx only" (see the manual pages I included in the .7z) and, while back then there were no forums, the newsgroups I used to participate in were full of dire warnings regarding HEAPX and Win 95, and I gave heed to them. But no, to be honest, no, I never did try it myself. So, if you want to give it a try, please do. BUT do make the *fullest* possible back-up before doing it. Care doesn't hurt. I believe it'll give you nothing more than a big intergalactic lock-up.
But it might be worse. I'll fish up my old SYSTEM.INI and post the relevant parts tomorrow, but I think that what is in Q136776 should be enough, together with the HURRICAN.INI in the .7z I posted. As you use Win ME, I'm betting you'll be the first ever to try HEAPX on it...
Yes, Nuts & Bolts and NETROOM were Helix other products. I seems to me that it was Nuts & Bolts McAffe was really after. NETROOM was much better than either Qualitas 386-to-the-MAX or Quarterdeck QEMM, not to mention M$ EMM386, at that point in time...
But it might be worse. I'll fish up my old SYSTEM.INI and post the relevant parts tomorrow, but I think that what is in Q136776 should be enough, together with the HURRICAN.INI in the .7z I posted. As you use Win ME, I'm betting you'll be the first ever to try HEAPX on it...Yes, Nuts & Bolts and NETROOM were Helix other products. I seems to me that it was Nuts & Bolts McAffe was really after. NETROOM was much better than either Qualitas 386-to-the-MAX or Quarterdeck QEMM, not to mention M$ EMM386, at that point in time...
QUOTE (BenoitRen @ Nov 19 2007, 06:33 AM)
QUOTE
All our problem does lie with the 16-bit heaps. The 32-bit heaps are large enough.
Alternatively, we could use more 32-bit applications.QUOTE (eidenk @ Nov 19 2007, 07:06 AM)
The depletion of 16bit resources is created by the running of 32bit apps. The more you run 32bit apps the more the 16bit segments of resources are depleted.
If someone is able to explain what takes place and why, it would be great.
If someone is able to explain what takes place and why, it would be great.
QUOTE (oscardog @ Nov 19 2007, 09:39 AM)
As far as I understand it (I could be wrong) user.exe 16 bit heap stores things like window classes, message queues and gdi.exe 16 bit heap stores logical pens, brushes so if any app 32bit or otherwise requires any of these, into the heap they go. Gdi.exe and user.exe heaps are in conventional memory the first 640kb of system memory and reside their for dos app compatibility a legacy from the first processors, which couldn't address over 1 MB of memory, in between is the uma for ROM, RAM on peripherals and memory-mapped input/output .
Gdi32.dll and user32.dll have no such limitations being purely for 32 bit apps, although the apps will still use some of the 16 bit heaps.
To overcome this everything in user.exe and gdi.exe has to reference a 32bit heap in the same manner as its 32bit counterparts, altering the global descriptor table to accomadate this, but this will break dos compatability. Whether as an alternative, the space of the uma can be absorbed as it is very rarely used these days, to increase the size of the 16bit heaps and keep dos compatability.
Just some thoughts.
Gdi32.dll and user32.dll have no such limitations being purely for 32 bit apps, although the apps will still use some of the 16 bit heaps.
To overcome this everything in user.exe and gdi.exe has to reference a 32bit heap in the same manner as its 32bit counterparts, altering the global descriptor table to accomadate this, but this will break dos compatability. Whether as an alternative, the space of the uma can be absorbed as it is very rarely used these days, to increase the size of the 16bit heaps and keep dos compatability.
Just some thoughts.
QUOTE (dencorso @ Nov 19 2007, 02:59 PM)
oscardog is precisely right, AFAIK. HEAPX worked in Win 3.xx because it implemented a kind of "heap paging" to free up space in the USER and GDI heaps...
eidenk, here are the lines to add to system.ini:
====================================================
[386Enh]
Device=C:\HURRIC98\HEAPX.386
[Hurricane]
HurricaneDirectory=C:\HURRIC98 ; this is whatever dir you have put the files in.
WindowsDirectory=C:\WINDOWS ; this is %windir%
====================================================
As you can see I was wrong v 2.02 already was called Hurricane 98 (but still Helix Hurricane 98).
Hurricane 95 is v. 2.00 (the installer, HURRI.EXE, is dated jul 16, 1998).
Good luck! As soon as I can I'll test it too, in a sandboxed plain-vanilla Win 98SE.
But I think the system resources are simply too different between Win 3.xx and 9x/ME for it to work.
eidenk, here are the lines to add to system.ini:
====================================================
[386Enh]
Device=C:\HURRIC98\HEAPX.386
[Hurricane]
HurricaneDirectory=C:\HURRIC98 ; this is whatever dir you have put the files in.
WindowsDirectory=C:\WINDOWS ; this is %windir%
====================================================
As you can see I was wrong v 2.02 already was called Hurricane 98 (but still Helix Hurricane 98).
Hurricane 95 is v. 2.00 (the installer, HURRI.EXE, is dated jul 16, 1998).
Good luck! As soon as I can I'll test it too, in a sandboxed plain-vanilla Win 98SE.
But I think the system resources are simply too different between Win 3.xx and 9x/ME for it to work.
QUOTE (Tihiy @ Nov 20 2007, 05:47 AM)
I've researched heap problems for some time, and i have some things to say:
> USER and GDI % you see in resource monitors are blatant lies; they are trimmed down to 99% after Explorer initializes, as Matt Pietrek says (in Undocumented Windows 95, if i remember correctly).
When you have 90% of USER and GDI resources, they're actually around 80% and 65%.
> GDI resources:
* I have "undocumented" structure references for Win3.1 floating around (for LOT of them!). They are mostly accurate for 9x too!
One more good thing: each GDI object has hOwner entry, which describes HTASK handle corresponding to task that allocated this GDI object. Bad thing: in 9x, a lot of entries may have bogus hOwner value. It may correspond to Win32 thread which died already, or was allocated by Win32 shared memory module, as it seems.
* The main local heap eaters are DCs. They're occupying ~266 bytes. That means that if your program allocates 30 device contexts, you can start only 7 copies of your program.
The good thing they're allocated as "moveable" structures, and memory DCs are usually not locked. Since that, "GDI Heap Extender" may be created, which will:
- Hook LocalAlloc/Lock/Unlock/Handle/Free. When moveable DC structure is allocated, it stores only some 'pointer' value, several bytes. When it is locked, it is actually allocated (moved back) into GDI local heap. When unlocked, it is moved back to our storage. I believe it is what Hurricane Heap Extender does.
-> I'm starting such a program. That won't be easy, since don't have any Win16 programming expirience. There are still a lot of questions, for example how would i allocate storage for real structures (if it'll be still 64K, there won't be much profit), will undocumented structures actually work, how dib and video drivers will react, etc.
>USER resources:
* That's completely another story. There are only fixed entries in local heap, and they're usually small. USER Local heap is exausted usually by thread message queries, or due to bug situations in Win32 when it becomes reentrant and loses track of itself.
> USER and GDI % you see in resource monitors are blatant lies; they are trimmed down to 99% after Explorer initializes, as Matt Pietrek says (in Undocumented Windows 95, if i remember correctly).
When you have 90% of USER and GDI resources, they're actually around 80% and 65%.
> GDI resources:
* I have "undocumented" structure references for Win3.1 floating around (for LOT of them!). They are mostly accurate for 9x too!
One more good thing: each GDI object has hOwner entry, which describes HTASK handle corresponding to task that allocated this GDI object. Bad thing: in 9x, a lot of entries may have bogus hOwner value. It may correspond to Win32 thread which died already, or was allocated by Win32 shared memory module, as it seems.
* The main local heap eaters are DCs. They're occupying ~266 bytes. That means that if your program allocates 30 device contexts, you can start only 7 copies of your program.
The good thing they're allocated as "moveable" structures, and memory DCs are usually not locked. Since that, "GDI Heap Extender" may be created, which will:
- Hook LocalAlloc/Lock/Unlock/Handle/Free. When moveable DC structure is allocated, it stores only some 'pointer' value, several bytes. When it is locked, it is actually allocated (moved back) into GDI local heap. When unlocked, it is moved back to our storage. I believe it is what Hurricane Heap Extender does.
-> I'm starting such a program. That won't be easy, since don't have any Win16 programming expirience. There are still a lot of questions, for example how would i allocate storage for real structures (if it'll be still 64K, there won't be much profit), will undocumented structures actually work, how dib and video drivers will react, etc.
>USER resources:
* That's completely another story. There are only fixed entries in local heap, and they're usually small. USER Local heap is exausted usually by thread message queries, or due to bug situations in Win32 when it becomes reentrant and loses track of itself.
QUOTE (BenoitRen @ Nov 20 2007, 11:06 AM)
QUOTE
As far as I understand it (I could be wrong) user.exe 16 bit heap stores things like window classes, message queues and gdi.exe 16 bit heap stores logical pens, brushes so if any app 32bit or otherwise requires any of these, into the heap they go. Gdi.exe and user.exe heaps are in conventional memory the first 640kb of system memory and reside their for dos app compatibility a legacy from the first processors, which couldn't address over 1 MB of memory.
I don't get it. Why are those things 16 bit for DOS compatibility? No DOS programs uses such things, as they're DOS programs, not Windows programs.QUOTE (oscardog @ Nov 20 2007, 01:06 PM)
Enhanced mode
Enhanced mode Windows rode squarely on the two main features introduced with the 80386: paging and virtual 8086 mode. Paging offered Windows the ability to use vast amounts of memory, even if there wasn't a corresponding amount of physical memory. This was done by using disk space to simulate real physical memory. Virtual 8086 mode enabled Windows to run MS-DOS-based programs in a processor simulation of an 8086 CPU. Ill-behaved MS-DOS-based programs were rarely able to bring down the entire system anymore.
Interestingly, enhanced mode Windows was superior to standard mode primarily because of additions underneath the standard mode code. The layer of ring 0 code known as the Virtual Machine Manager (VMM), along with Virtual Device Drivers (VxDs), introduced the architecture that still powers Windows 98. This ring 0 code did many things, but the two most powerful were page-based memory management and virtual machines.
Enhanced mode Windows implemented page-based memory management, but this fact was essentially invisible to applications and the ring 3 system components; the VMM simply made a bigger pool of memory for the system to allocate from. All user mode code still dealt with segments and was oblivious to the fact that physical memory might not be assigned to a segment at any particular point in time.
Virtual machines allowed Windows-based applications and multiple MS-DOS prompts to run concurrently, with each believing that it had sole control of the keyboard, mouse, screen, and so forth. All Windows-based applications ran in a single virtual machine reserved for their use. This was made possible by the virtual 8086 mode support introduced with the 80386.
As an interesting note, the ring 3 components of enhanced mode Windows were nearly identical to the standard mode components. Components such as window management (USER.EXE) and graphics (GDI.EXE) used the same code in both modes. The only significant difference between the two modes was in the kernel (KRNL286.EXE versus KRNL386.EXE), and in how MS-DOS-based programs were run.
@Tihiy Great to hear, I wish you every sucess. I understand that the 2m heaps overlap the 128k heap (i am assuming this is the 2 x 64k heaps) and enables a single selector. I need to do some more research though to make things clearer
@dencorso thanks for the file, I have tested it under a minimised win98se system with a 95 shell and the bootlog shows the driver being successfully loaded. I created 2 system.ini`s 1 with the driver 1 without and loaded up on each gdi.exe with multiple winrars until system resources became critical, both seem to be able to handle 21 winrar windows open before gdi.exe reached 1%. I will try to run this on a 98 shell where I can monitor memory and see if the driver is actually doing its part. The system seemed fine with the driverinstalled and had no ill effects.
Enhanced mode Windows rode squarely on the two main features introduced with the 80386: paging and virtual 8086 mode. Paging offered Windows the ability to use vast amounts of memory, even if there wasn't a corresponding amount of physical memory. This was done by using disk space to simulate real physical memory. Virtual 8086 mode enabled Windows to run MS-DOS-based programs in a processor simulation of an 8086 CPU. Ill-behaved MS-DOS-based programs were rarely able to bring down the entire system anymore.
Interestingly, enhanced mode Windows was superior to standard mode primarily because of additions underneath the standard mode code. The layer of ring 0 code known as the Virtual Machine Manager (VMM), along with Virtual Device Drivers (VxDs), introduced the architecture that still powers Windows 98. This ring 0 code did many things, but the two most powerful were page-based memory management and virtual machines.
Enhanced mode Windows implemented page-based memory management, but this fact was essentially invisible to applications and the ring 3 system components; the VMM simply made a bigger pool of memory for the system to allocate from. All user mode code still dealt with segments and was oblivious to the fact that physical memory might not be assigned to a segment at any particular point in time.
Virtual machines allowed Windows-based applications and multiple MS-DOS prompts to run concurrently, with each believing that it had sole control of the keyboard, mouse, screen, and so forth. All Windows-based applications ran in a single virtual machine reserved for their use. This was made possible by the virtual 8086 mode support introduced with the 80386.
As an interesting note, the ring 3 components of enhanced mode Windows were nearly identical to the standard mode components. Components such as window management (USER.EXE) and graphics (GDI.EXE) used the same code in both modes. The only significant difference between the two modes was in the kernel (KRNL286.EXE versus KRNL386.EXE), and in how MS-DOS-based programs were run.
@Tihiy Great to hear, I wish you every sucess. I understand that the 2m heaps overlap the 128k heap (i am assuming this is the 2 x 64k heaps) and enables a single selector. I need to do some more research though to make things clearer
@dencorso thanks for the file, I have tested it under a minimised win98se system with a 95 shell and the bootlog shows the driver being successfully loaded. I created 2 system.ini`s 1 with the driver 1 without and loaded up on each gdi.exe with multiple winrars until system resources became critical, both seem to be able to handle 21 winrar windows open before gdi.exe reached 1%. I will try to run this on a 98 shell where I can monitor memory and see if the driver is actually doing its part. The system seemed fine with the driverinstalled and had no ill effects.
QUOTE (dencorso @ Nov 20 2007, 02:44 PM)
@BenoitRen: To complement what oscardog has just said, Windows Standard Mode was nothing more than a sophisticated DOS Extender...
@oscardog: Wow! You did it!: Did you load both from system.ini, heapx.386 from a "device=" line in [386Enh] and heapx.drv from a "Heapx.Drv=<path>\HEAPX.DRV" in [boot]? Or how did you manage to have it load? Glad to know you didn't get just a systems-wide crash! This sure has to be explored further.
@oscardog: Wow! You did it!
: Did you load both from system.ini, heapx.386 from a "device=" line in [386Enh] and heapx.drv from a "Heapx.Drv=<path>\HEAPX.DRV" in [boot]? Or how did you manage to have it load? Glad to know you didn't get just a systems-wide crash! This sure has to be explored further.QUOTE (oscardog @ Nov 21 2007, 08:44 PM)
I have heapx.drv=c:\heapx\heapx.drv in [boot]
Device=C:\heapx\HEAPX.386 in [386Enh]
[Hurricane]
HurricaneDirectory=C:\heapx
WindowsDirectory=C:\MINDOWS
and altered Hurrican.ini to
[SysLoader]
GlobMem.Drv=C:\HURRICAN\GLOBMEM.DRV
Heapx.Drv=C:\heapx\HEAPX.DRV
WinGuard.Drv=C:\HURRICAN\WINGUARD.DRV
I am not sure if anything is being activated on the thresholds set as both with and without the driver free
resources seem to be the same despite resources being below them. Perhaps it has a dependancy on other
files, I will try to get the full package and see if that rectifys things. Bootlog shows the driver loading
successfully.
As a side note I see in the hurrican.ini references to cleanuponclose and compactonclose this reminded me of
the UserSeeUserDo function in user.exe which subfunctions allow allocate,free and compact in the user 16bit
heap. So at least this heap can be modified at will and I suspect this is what heapx is doing. Unfortunately as
Tihiy mentions this is the lesser of the problem heaps
Device=C:\heapx\HEAPX.386 in [386Enh]
[Hurricane]
HurricaneDirectory=C:\heapx
WindowsDirectory=C:\MINDOWS
and altered Hurrican.ini to
[SysLoader]
GlobMem.Drv=C:\HURRICAN\GLOBMEM.DRV
Heapx.Drv=C:\heapx\HEAPX.DRV
WinGuard.Drv=C:\HURRICAN\WINGUARD.DRV
I am not sure if anything is being activated on the thresholds set as both with and without the driver free
resources seem to be the same despite resources being below them. Perhaps it has a dependancy on other
files, I will try to get the full package and see if that rectifys things. Bootlog shows the driver loading
successfully.
As a side note I see in the hurrican.ini references to cleanuponclose and compactonclose this reminded me of
the UserSeeUserDo function in user.exe which subfunctions allow allocate,free and compact in the user 16bit
heap. So at least this heap can be modified at will and I suspect this is what heapx is doing. Unfortunately as
Tihiy mentions this is the lesser of the problem heaps
QUOTE (dencorso @ Nov 24 2007, 03:47 PM)
Hi, oscardog!
I've done some testing myself, and I can cornfirm HEAPX.386 is loaded and initialized correctly, and then sits
there as a Stactic VxD without causing any ill effects to the system. All initialization steps are documented in
bootlog.txt, and both Norton Utilities System Information - Memory and APSoft VxDView find it in memory,
under the name VHEAPX (it has a PM API but offers no VxD Services). So far, so good. As it's harmless, it
may be of help to Tihiy's projected GDI Expander, provided we can understand what it does do. To me it
seems a monitoring VxD, but it also could be an interceptor VxD.
As for HEAPX.DRV, that's another story, entirely:
On one hand, the line heapx.drv=<path>\heapx.drv in [boot], in system.ini in totally ignored by Win 98SE,
during initialization. So, the system initializes normally, but there is no sign of heapx.drv anywhere in memory.
On the other hand, by adding it to the end of the devices= line in [boot], in system.ini, Win 98SE does try to
load it and soon gives a box that says "MSGSRV32 An error has occurred in your application. Etc." At this
point there are two choices: close or ignore. When I chose close, I then got "MSGSRV32 caused a GPS in
module HEAPX.DRV at 0001:00008BAE". I closed this message box too, and the system froze. Only
<ctrl><alt><del> still worked, but the only option I had was to shut down. When I choose ignore, I got an
instant BSOD, saying "Fatal Exception 0E has occurred at 01A7:BFF9E0B7". I told it to proceed, it returned to
the windows initialization and then gave me "MSGSRV32 caused a GPS in module KRNL386.EXE at
0002:00000102". I closed this message box too, and the system froze dead. Nothing worked anymore. After
restarting in DOS and editing out heapx.drv from the drivers= line, everyting returned to normal.
I'm sorry I wasn't able to bring good news,
but those are my findings.
I've done some testing myself, and I can cornfirm HEAPX.386 is loaded and initialized correctly, and then sits
there as a Stactic VxD without causing any ill effects to the system. All initialization steps are documented in
bootlog.txt, and both Norton Utilities System Information - Memory and APSoft VxDView find it in memory,
under the name VHEAPX (it has a PM API but offers no VxD Services). So far, so good. As it's harmless, it
may be of help to Tihiy's projected GDI Expander, provided we can understand what it does do. To me it
seems a monitoring VxD, but it also could be an interceptor VxD.
As for HEAPX.DRV, that's another story, entirely:
On one hand, the line heapx.drv=<path>\heapx.drv in [boot], in system.ini in totally ignored by Win 98SE,
during initialization. So, the system initializes normally, but there is no sign of heapx.drv anywhere in memory.
On the other hand, by adding it to the end of the devices= line in [boot], in system.ini, Win 98SE does try to
load it and soon gives a box that says "MSGSRV32 An error has occurred in your application. Etc." At this
point there are two choices: close or ignore. When I chose close, I then got "MSGSRV32 caused a GPS in
module HEAPX.DRV at 0001:00008BAE". I closed this message box too, and the system froze. Only
<ctrl><alt><del> still worked, but the only option I had was to shut down. When I choose ignore, I got an
instant BSOD, saying "Fatal Exception 0E has occurred at 01A7:BFF9E0B7". I told it to proceed, it returned to
the windows initialization and then gave me "MSGSRV32 caused a GPS in module KRNL386.EXE at
0002:00000102". I closed this message box too, and the system froze dead. Nothing worked anymore. After
restarting in DOS and editing out heapx.drv from the drivers= line, everyting returned to normal.
I'm sorry I wasn't able to bring good news,
but those are my findings.QUOTE (oscardog @ Nov 30 2007, 05:21 AM)
The cleanuponclose and compactonclose of the hurrican.ini was well worth the effort of examing heapx.
I have very little in the way of good gdi information, hopefully a book coming soon might help a little, from what
I have found is that the 32bit GDI heap start 128k past the 16bit dgroup and use the same selector and store
offsets relative to the base address of the gdi dgroup selector.
I was wondering that if this is the case, if the PENS,BRUSHES, etc could all be placed in the
32 bit heap. IsGDIObject figures out which heap it should look for the object in via 16 bit handles ending in
2,6,0xA or 0xE, handles for objects in the 32bit heap are multiples of 4. IsGDIObject then calculates this
address and constructs a pointer to it. I am not sure if HGDIOBJ would cause complications if this was to be
done, or if the header files would need modifying more.
I have very little in the way of good gdi information, hopefully a book coming soon might help a little, from what
I have found is that the 32bit GDI heap start 128k past the 16bit dgroup and use the same selector and store
offsets relative to the base address of the gdi dgroup selector.
I was wondering that if this is the case, if the PENS,BRUSHES, etc could all be placed in the
32 bit heap. IsGDIObject figures out which heap it should look for the object in via 16 bit handles ending in
2,6,0xA or 0xE, handles for objects in the 32bit heap are multiples of 4. IsGDIObject then calculates this
address and constructs a pointer to it. I am not sure if HGDIOBJ would cause complications if this was to be
done, or if the header files would need modifying more.
QUOTE (rloew @ Nov 30 2007, 11:46 PM)
I examined the code for GetObjectType which is the recommended alternative to IsGDIObject for 32 Bit Code.
It appears to process four types of Handles.
1. Selector Handles (value = 3 mod 4)
2. 32 Bit Mode Handles (value = 0 mod 4)
3. New Style 16 Bit Handles (value = 2 mod 4)
4. Old Style 16 Bit Handles (value = 2 mod 4)
The Selector Handles are not connected to the GDI Resource Heap so they are not relevant to the Resource
issue.
The 32 Bit Mode Handles are offsets into a 64K Index Table which contains 32 bit offsets to the 32 Bit
Resource Area. Offsets are relative to the 64K Resource Area.
The two styles of 16 Bit Handles are offsets into the 64K Resource Heap. They point to 4 Byte entries.
Bit 6 of the third Byte determines the style. If set, the entry is a New Style Entry, otherwise it is the Old Style.
In the New Style Entry, the first two bytes are a 32 Bit Mode Handle (See #2 above) which is used to access
the 32 Bit Resource Area.
In the Old Style Entry, the first two bytes are a 16 Bit offset within the 64K Resource Heap.
The Resource is laid out as follows:
64K Resource Heap
64K Index Table
32 Bit Resource Area
This explains the 128K separation between the two Resource Areas that Oscardog noted.
Considering how easy it is to set the New Style flag and use the 32 Bit Resource Area, I suspect there is a
reason why Microsoft did not move all Resources out of the 64K Heap.
It appears to process four types of Handles.
1. Selector Handles (value = 3 mod 4)
2. 32 Bit Mode Handles (value = 0 mod 4)
3. New Style 16 Bit Handles (value = 2 mod 4)
4. Old Style 16 Bit Handles (value = 2 mod 4)
The Selector Handles are not connected to the GDI Resource Heap so they are not relevant to the Resource
issue.
The 32 Bit Mode Handles are offsets into a 64K Index Table which contains 32 bit offsets to the 32 Bit
Resource Area. Offsets are relative to the 64K Resource Area.
The two styles of 16 Bit Handles are offsets into the 64K Resource Heap. They point to 4 Byte entries.
Bit 6 of the third Byte determines the style. If set, the entry is a New Style Entry, otherwise it is the Old Style.
In the New Style Entry, the first two bytes are a 32 Bit Mode Handle (See #2 above) which is used to access
the 32 Bit Resource Area.
In the Old Style Entry, the first two bytes are a 16 Bit offset within the 64K Resource Heap.
The Resource is laid out as follows:
64K Resource Heap
64K Index Table
32 Bit Resource Area
This explains the 128K separation between the two Resource Areas that Oscardog noted.
Considering how easy it is to set the New Style flag and use the 32 Bit Resource Area, I suspect there is a
reason why Microsoft did not move all Resources out of the 64K Heap.
QUOTE (Tihiy @ Dec 01 2007, 05:20 AM)
In order not to repeat 13-year old research, here's the Windows 95 System programming secrets:
http://tihiy.ahanix.org/asmmetpitr.rar
http://tihiy.ahanix.org/asmmetpitr.rar
QUOTE (oscardog @ Dec 01 2007, 08:08 AM)
Many thanks
@rloew I guess those remaining in the 64k heap are for backwards compatibility, whether users are willing to
forego this for larger system resources, or perhaps made selectable on boot
@rloew I guess those remaining in the 64k heap are for backwards compatibility, whether users are willing to
forego this for larger system resources, or perhaps made selectable on boot
QUOTE (oscardog @ Dec 14 2007, 02:48 PM)
As Tihiy states and contrary to what we have been told before regarding resource limitations, the main
problem are DC`s. Particulary the over use in applications in using CS_OWNDC in creating private DC`s
which very quickly consume the heap, when apps i.e not involved in cad, video editing do not require a boost
in graphics performance and could well use common DC`s leaving much much more resources free.
problem are DC`s. Particulary the over use in applications in using CS_OWNDC in creating private DC`s
which very quickly consume the heap, when apps i.e not involved in cad, video editing do not require a boost
in graphics performance and could well use common DC`s leaving much much more resources free.
QUOTE (rloew @ Dec 24 2007, 01:02 PM)
The Resource code is mostly 16-Bit Code, thunked down from 32-Bits as needed. So far, it appears that each Object type is individually coded, so moving them would be a substantial undertaking to find all the references to each one.
Running 14 IE6 instances of NASA's "Today's Space Weather" used up all of the 16-Bit Resources. The most obvious object in the GDI 16-Bit Heap was the 40 Byte Bitmap Object.
Running 14 IE6 instances of NASA's "Today's Space Weather" used up all of the 16-Bit Resources. The most obvious object in the GDI 16-Bit Heap was the 40 Byte Bitmap Object.
QUOTE (Tihiy @ Dec 24 2007, 01:39 PM)
Pardon me, but where did you find 40 byte bitmap entries?
Also, on topic: actually, my idea with hooking LocalAlloc/Lock etc is not able to solve anything, since (as
known from Matt Pietrek book) GDI does not uses LocalLock but just abuses locked handle as 16-bit pointer
into real local memory arena.
CODE
Entry: Handle- 4210 Address- 51846 Size- 34 Flags- movble Locks- 0 Type - 5 Type - KO hOwner - 14598 Owner name - Iexplore
Entry: Handle- 2558 Address- 57062 Size- 46 Flags- movble Locks- 0 Type - 5 Type - KO hOwner - 10126 Owner name - Explorer
I've never seen 40 byte ones with various GDI versions.Entry: Handle- 2558 Address- 57062 Size- 46 Flags- movble Locks- 0 Type - 5 Type - KO hOwner - 10126 Owner name - Explorer
Also, on topic: actually, my idea with hooking LocalAlloc/Lock etc is not able to solve anything, since (as
known from Matt Pietrek book) GDI does not uses LocalLock but just abuses locked handle as 16-bit pointer
into real local memory arena.
QUOTE (rloew @ Dec 24 2007, 01:58 PM)
QUOTE
I've never seen 40 byte ones with various GDI versions.
The total space used by each Bitmap record I saw was 40 Bytes. The record itself may be 34 Bytes with a 6 Byte Header.QUOTE
CODE
Entry: Handle- 4210 Address- 51846 Size- 34 Flags- movble Locks- 0 Type- 5 Type - KO hOwner - 14598 Owner name - Iexplore
Entry: Handle- 2558 Address- 57062 Size- 46 Flags- movble Locks- 0 Type- 5 Type - KO hOwner - 10126 Owner name - Explorer
Entry: Handle- 2558 Address- 57062 Size- 46 Flags- movble Locks- 0 Type- 5 Type - KO hOwner - 10126 Owner name - Explorer
The actual space used for these Bitmaps is 44 Bytes each if you include the Handle as well.
Note: There is no more. This is where the old tread broke off.
And now, here're some great news:
The quotation below is post #522 from the UberSkin thread:
QUOTE (Tihiy @ Mar 4 2009, 09:55 AM) 
QUOTE
Tihiy, have you tested (extensively) UberSkin under Win98SE with the patched GDI32.DLL/GDI.EXE 4.90.3003 ? I can't think of a better reason for the (occasional with UberSkin 8.3.6 and much more frequent with later versions) out-of-the-blue GDI crashes (while resources are at 40-50% or better).
Yep, i figured out GDI troubles. Those crashes / hangs / BSODs are caused by bugs in programs you're using (Miranda as one of them). I've created technology called GDI salvation which successfully fights with buggy programs and resource leaks. Stay tuned.
Thanks dencorso
I wouldn't use helix heap extender as a way to solve the GDI resource problem
http://support.microsoft.com/kb/136776
Quote from MS:
"Hurricane and its utilities are incompatible with Windows"
http://support.microsoft.com/kb/136776
Quote from MS:
"Hurricane and its utilities are incompatible with Windows"
@eidenk: You're welcome! I'm glad you started a topic on this subject once more.
@blackwire: Well, Microsoft said it, about Hurricane and Win 9x. And also said: "Upgrade to Helix Hurricane version 2.0 or later." All along, Helix also said that no version of Heap Expander was compatible with Win 95. Note that, for Win 3.1 and WfW 3.11, Heap Expander worked beautifully, all right! But when Microsoft modified the workings of the resources, with Win 95, Helix was at the end of its run, and never developed the Win 95 version. In our tests oscardog and I used the latest available version of Heap Expander, just to see what happened, and to perhaps get some ideas out of it. It seems we got nowhere, after all... But that's past already.
For the present, I prefer to believe Tihiy's GDI Salvation will solve once and for all the GDI resources problems, that's why I'm so excited about it. Then, half of the problem will have been solved, there remaining just the USER resources problem. I believe Tihiy said somewhere, around late 2007 or early 2008, that he thought his own approach wouldn't work also for the USER resources.
And then he went silent about the resources problem, AFAIK, until that post I quoted at the end of post #4...
@blackwire: Well, Microsoft said it, about Hurricane and Win 9x. And also said: "Upgrade to Helix Hurricane version 2.0 or later." All along, Helix also said that no version of Heap Expander was compatible with Win 95. Note that, for Win 3.1 and WfW 3.11, Heap Expander worked beautifully, all right! But when Microsoft modified the workings of the resources, with Win 95, Helix was at the end of its run, and never developed the Win 95 version.
In our tests oscardog and I used the latest available version of Heap Expander, just to see what happened, and to perhaps get some ideas out of it. It seems we got nowhere, after all... But that's past already. For the present, I prefer to believe Tihiy's GDI Salvation will solve once and for all the GDI resources problems, that's why I'm so excited about it.
Then, half of the problem will have been solved, there remaining just the USER resources problem. I believe Tihiy said somewhere, around late 2007 or early 2008, that he thought his own approach wouldn't work also for the USER resources. And then he went silent about the resources problem, AFAIK, until that post I quoted at the end of post #4...
QUOTE
Tihiy's GDI Salvation will solve once and for all the GDI resources problems, that's why I'm so excited about it.
Unfortunately NO. As i said, it >>fights with buggy programs and resource leaks. Not more. It can't expand heap beyond 64K.
You could do it if you wanted to. 
Untap the bottle (not the vodka one 
) and let the genius out. 
Untap the bottle (not the vodka one ) and let the genius out. QUOTE (Tihiy @ Mar 12 2009, 01:57 PM)
QUOTE
Tihiy's GDI Salvation will solve once and for all the GDI resources problems, that's why I'm so excited about it.
Unfortunately NO. As i said, it >>fights with buggy programs and resource leaks. Not more. It can't expand heap beyond 64K.OK. Right. Maybe I'm overenthusiastic. Nothing can really expand 16-bit segments beyound 64 KiB, of course. That's built-in on the design of the 80X86 family. But recovering from buggy programs and resource leaks is a giant step forward. Well-behaved programs rarely exhaust the GDI resources. I was thinking somewhat along the line of recovering from unexpected behaviour when I dreamed about the putative "sfix.vxd" (at the 1st quote at the top of post #3). rloew didn't find the ideia workable, but, then again, maybe he was thinking on really solving all types of resource exhaustion. My ideia was, and remains, that even solving just some of them is worthwhile. Now, please, do tell me: will GDI Salvation have a stand-alone version, or do you intend to release it only integrated with UberSkin? I'm sure that a stand-alone version will be much welcome, and reach a broader user base. I think UberSkin rocks. But I do envisage it as a separate entity from programs dealing with the resources issue. And thanks a lot for returning to this discussion, now that it has been restarted. You do rock!
QUOTE (dencorso @ Mar 12 2009, 11:15 AM)
Now, please, do tell me: will GDI Salvation have a stand-alone version, or do you intend to release it only integrated with UberSkin?
Have you looked at/used UberSkin? You don't have to use any of the skinning to get its other benefits (which right now are primarily taskbar locking, closing hung programs by right clicking them on the taskbar, and resolving file copying hanging Explorer with IE6). A release of UberSkin that doesn't include any skins and has a different name, like UberHeap (kidding), could be an option but totally isn't necessary. Just make it clear that UberSkin is awesome (and fixes some Windows bugs) and that using the skins isn't required, and that it's worth installing on any 98SE/ME machine.
Queue
Since i fail to deliver guide, i'll tell you how GDI Salvation works here:
1) Handle protection. 9x lacks proper GDI handle validation which may result in incorrect memory access or wrong resource deletion and as result crash, hang or BSOD. Which is not-so-rare: i know a lot of programs which try to delete deleted handles or wrong handles (icon handles for example).
2) Handle arena cleaning. GDI relies on moveable 16-bit handles. Too bad that they require significant memory overhead, since handle arenas are allocated in heap too. Worse, they're never freed (by design?): that's why when you quit heavyweight programs GDI resources don't go up back. Even worse, they can fill most heap and make whole system slow crashing a**. RP9 addresses this by running through those arenas and removing free ones. This run is performed after every app termination or when resource allocation fails. It's disabled for first 60 seconds of system uptime and you can diable it through RPConfig.
Test numbers: try running programs which consume much GDI. I've runned 3 ImgBurns. After exiting them, without GDISalv 9% of GDI were lost.
3) Leak protection. Bizzare bug, but 'extended pen' GDI objects are somehow not marked with owner, meaning they can leak permanently. This was corrected in 9.0.2.
USER Salvation was explained before. In short, it saves >100 bytes per process by combining comctl32 classes with system classes. Not much, but you can run 60% more Notepad copies on clean system.
Writing a proper heap expander, with proper performance and compatibility is an extremely hard task.
1) Handle protection. 9x lacks proper GDI handle validation which may result in incorrect memory access or wrong resource deletion and as result crash, hang or BSOD. Which is not-so-rare: i know a lot of programs which try to delete deleted handles or wrong handles (icon handles for example).
2) Handle arena cleaning. GDI relies on moveable 16-bit handles. Too bad that they require significant memory overhead, since handle arenas are allocated in heap too. Worse, they're never freed (by design?): that's why when you quit heavyweight programs GDI resources don't go up back. Even worse, they can fill most heap and make whole system slow crashing a**. RP9 addresses this by running through those arenas and removing free ones. This run is performed after every app termination or when resource allocation fails. It's disabled for first 60 seconds of system uptime and you can diable it through RPConfig.
Test numbers: try running programs which consume much GDI. I've runned 3 ImgBurns. After exiting them, without GDISalv 9% of GDI were lost.
3) Leak protection. Bizzare bug, but 'extended pen' GDI objects are somehow not marked with owner, meaning they can leak permanently. This was corrected in 9.0.2.
USER Salvation was explained before. In short, it saves >100 bytes per process by combining comctl32 classes with system classes. Not much, but you can run 60% more Notepad copies on clean system.
Writing a proper heap expander, with proper performance and compatibility is an extremely hard task.
Very interesting details! Can't wait to test this technique (be it in alpha/beta stage - I'm used to that).
I suspect my sudden GDI crashes may occur due to overloaded registry (16MB+ all in all) and I'm extremely curious if this technique can help in this case.
I suspect my sudden GDI crashes may occur due to overloaded registry (16MB+ all in all) and I'm extremely curious if this technique can help in this case.
QUOTE ("Tihiy")
Writing a proper heap expander, with proper performance and compatibility is an extremely hard task.
And who else would be the best one to take a stab at it...? QUOTE
Can't wait to test this technique (be it in alpha/beta stage - I'm used to that).
Eh, it's already in released RP9.
Why am I always the last to know about such important news...? 
On to it now; thanks for the heads up.
On to it now; thanks for the heads up.
QUOTE (Tihiy @ Mar 15 2009, 08:23 PM)
1) Handle protection. 9x lacks proper GDI handle validation which may result in incorrect memory access or wrong
...
USER Salvation was explained before. In short, it saves >100 bytes per process by combining comctl32 classes with system classes. Not much, but you can run 60% more Notepad copies on clean system.
...
USER Salvation was explained before. In short, it saves >100 bytes per process by combining comctl32 classes with system classes. Not much, but you can run 60% more Notepad copies on clean system.
Tihiy, could you copy all these information to your first few posts of RP9? I think it necessary to let more people know the "resource salvation" side of RP9. There are still many people (like me) using Win98 heavily at work. System stability is very important to us
Thank you
QUOTE
I think it necessary to let more people know the "resource salvation" side of RP9.
Of course it is. I just lack time to compile all info about RP9.
I've just installed RP9. I did a full install. I am not using any skin, nor 32-bit icons at the moment, but I'm using ClearType. Here're my first impressions:
Before RP9, just after system startup: 57% USER resources & 82% GDI resources.
After RP9, just after system startup: 71% USER resources & 81% GDI resources.
And the resource drain is much slower, and resource recovery (after working for some time and then closing every aplication that was not open just after startup) is much better.
Wow! Wonderful!
Thanks a whole lot Tihiy! Keep on the great work! You rock!
Before RP9, just after system startup: 57% USER resources & 82% GDI resources.
After RP9, just after system startup: 71% USER resources & 81% GDI resources.
And the resource drain is much slower, and resource recovery (after working for some time and then closing every aplication that was not open just after startup) is much better.
Wow!
Wonderful! Thanks a whole lot Tihiy! Keep on the great work! You rock!
Results reported by RetroOS on post #60 in the RP9 thread:
I took the liberty to quote it here because it's relevant to this thread's main topic.
QUOTE (RetroOS @ Mar 20 2009, 09:45 AM)
Okay, RP9 officially ROCKS!
No change in GDI, but USER resources went UP 7% from no RP to after installing RP9!!!
That is so ultimately awesome!
It was the USER resources that I always had a problem with.
Testing so far is all good.[...]
No change in GDI, but USER resources went UP 7% from no RP to after installing RP9!!!
That is so ultimately awesome!
It was the USER resources that I always had a problem with.
Testing so far is all good.[...]
I took the liberty to quote it here because it's relevant to this thread's main topic.
Well, if your USER percentages go up that high, i have bad news for ya 
It can only mean that there's too much resource intensive apps are in startup.
It can only mean that there's too much resource intensive apps are in startup.
QUOTE (Tihiy @ Mar 20 2009, 11:16 AM)
Well, if your USER percentages go up that high, i have bad news for ya
It can only mean that there's too much resource intensive apps are in startup.
It can only mean that there's too much resource intensive apps are in startup.
No, no, it's GOOD news. They're talking about how much FREE resources they have. When they say resources went ''up'' by 7%, they mean 7% more free resources.
Queue
No, that's bad news. Since percents are trimmed by amount of resources left after startup programs, it means those programs eat too much resources.
I saw 3% up max.
I saw 3% up max.
QUOTE (Tihiy @ Mar 20 2009, 03:16 PM)
Well, if your USER percentages go up that high, i have bad news for ya
It can only mean that there's too much resource intensive apps are in startup.
Sure, Tihiy! It can only mean that there's too much resource intensive apps are in startup.
But those are real-life configurations:
RetroOS machine's USER resources had a 7% free increase.
Mine own machine's USER resources had a 14% free increase.
Of course, I've got many real programs in start-up that do IMHO useful things, like Pop Up Killer 1.45.5, HDDHealth 2.1 and Disk Space Monitor 1.0b4 ... At any moment, from start-up onwards, I have at least 16 icons in the system tray. I've trimmed my start-up configuration to the limit. I can't do without any of the programs in the tray. I need the things they do.
Now you know why we are talking about "Heaps Expansion" since 2007... Of course, now the name of the subject might as well be changed to "Resources Salvation".
But these real-life examples illustrate well the situation: even little improvements in resource management lead to impressive results, because people run many real programs from start-up onwards. Thanks to your efforts, our systems are much better now. You do rock!
QUOTE (Tihiy @ Mar 20 2009, 11:41 AM)
No, that's bad news. Since percents are trimmed by amount of resources left after startup programs, it means those programs eat too much resources.
I saw 3% up max.
I saw 3% up max.
Ahhh, now I understand.
And dencorso... your system tray is an abomination. ^_^ Mine has two icons, and that's two too-many. The speaker icon (which I leave just so I always have one thing, because truthfully an empty system tray is weird) and ZoneAlarm. The only other thing I have run at startup is TweakUI.
Queue
QUOTE (Queue @ Mar 20 2009, 04:32 PM)
And dencorso... your system tray is an abomination. ^_^ Mine has two icons, and that's two too-many. The speaker icon (which I leave just so I always have one thing, because truthfully an empty system tray is weird) and ZoneAlarm. The only other thing I have run at startup is TweakUI.
Yes, I know!
Then again, my system is quite stable, and before RP9 I already had > 40h uptimes easily...Now it's bound to be even better, because it was the resources that usually caused me to reboot.
BTW, I do run Tweak UI, too. I didn't mention it because it doesn't add any icon to the tray, so I forgot about it.
And I do run the much maligned Norton Crash Guard, that never gave me any grief, and time and again helped me avoid a reboot.
Here, however, YMMV aplies, of course! 
Hi folks!
Just to get my 7% USER resources increase in perspective...
Without RP or UberSkin, I had 77% USER resources free and 97% GDI resources free...
I always trim down unneeded startup apps.
With RP9 installed, I get 84% USER resources free and 97-98% GDI resources free (It sits at 97%, but sometimes it's 98% - I never saw it above 97% without RP9...)
I know Tihiy thinks this kind of increase is bad (from a technical viewpoint), but I think it's good!
So, to conclude, it would appear that RP9 is doing good things by freeing wasted resources.
Just to get my 7% USER resources increase in perspective...
Without RP or UberSkin, I had 77% USER resources free and 97% GDI resources free...
I always trim down unneeded startup apps.
With RP9 installed, I get 84% USER resources free and 97-98% GDI resources free (It sits at 97%, but sometimes it's 98% - I never saw it above 97% without RP9...)
I know Tihiy thinks this kind of increase is bad (from a technical viewpoint), but I think it's good!
So, to conclude, it would appear that RP9 is doing good things by freeing wasted resources.
I've been thinking about the GDI resources limit while reading this thread from the beginning. There are many opinions telling it can not be done.
My conclusion is, it was done somehow in Windows 2000. Since the same applications are working in Windows 2000 and 98, it should be possible to increase the resource limit in 98 without recompilation of the user applications.
I would like to know how Windows 2000 does manage the GDI resources. And where is the difference from the Windows 98 point of view.
My conclusion is, it was done somehow in Windows 2000. Since the same applications are working in Windows 2000 and 98, it should be possible to increase the resource limit in 98 without recompilation of the user applications.
I would like to know how Windows 2000 does manage the GDI resources. And where is the difference from the Windows 98 point of view.
QUOTE (Sfor @ Mar 21 2009, 11:56 PM)
...
My conclusion is, it was done somehow in Windows 2000. Since the same applications are working in Windows 2000 and 98, it should be possible to increase the resource limit in 98 without recompilation of the user applications.
...
My conclusion is, it was done somehow in Windows 2000. Since the same applications are working in Windows 2000 and 98, it should be possible to increase the resource limit in 98 without recompilation of the user applications.
...
That is exactly what has been bugging me for years!
Windows 2000 onwards will run many of the apps that run on 9x.
However, they don't have the same kind of resources issues.
So... It is technically possible...
Whether it could be done is quite another problem.
I expect it would require extensive modifications to the Windows kernel...
Quick reference index of information about RP9 by Tihiy himself:
USER Salvation
GDI Salvation
additional functionality
USER Salvation
GDI Salvation
additional functionality
QUOTE (RetroOS @ Mar 21 2009, 01:52 PM)
That is exactly what has been bugging me for years!
Windows 2000 onwards will run many of the apps that run on 9x.
However, they don't have the same kind of resources issues.
So... It is technically possible...
Windows 2000 onwards will run many of the apps that run on 9x.
However, they don't have the same kind of resources issues.
So... It is technically possible...
Wrong analogy. There are also plenty apps that run on w2k and onwards but will never run on win9x by design. Kernel modifications like KernelEx don't change this.
QUOTE (noguru @ Mar 22 2009, 10:41 AM)
QUOTE (RetroOS @ Mar 21 2009, 01:52 PM)
That is exactly what has been bugging me for years!
Windows 2000 onwards will run many of the apps that run on 9x.
However, they don't have the same kind of resources issues.
So... It is technically possible...
Windows 2000 onwards will run many of the apps that run on 9x.
However, they don't have the same kind of resources issues.
So... It is technically possible...
Wrong analogy. There are also plenty apps that run on w2k and onwards but will never run on win9x by design. Kernel modifications like KernelEx don't change this.
The analogy was a correct one, I believe.
All applications suffering from the GDI resource limits on Windows 98 are working on Windows 2000 with no apparent GDI shortages. The applications designed for just Windows 2000 are not a problem, since they do not work in Windows 98.
The thread adresses Windows 98 and compatible applications related problems. Applications not compatible with Windows 98 are out of the scope, in my opinion.
QUOTE (Sfor @ Mar 22 2009, 12:52 PM)
All applications suffering from the GDI resource limits on Windows 98 are working on Windows 2000 with no apparent GDI shortages. The applications designed for just Windows 2000 are not a problem, since they do not work in Windows 98.
The thread adresses Windows 98 and compatible applications related problems. Applications not compatible with Windows 98 are out of the scope, in my opinion.
The thread adresses Windows 98 and compatible applications related problems. Applications not compatible with Windows 98 are out of the scope, in my opinion.
This thread is not about any apps but about 16bit resources limitation (64Kb) in Win9x. A limitation that doesn't exist in Win2k. That's why you can't compare them even when running the same software.
QUOTE (noguru @ Mar 22 2009, 10:21 AM)
A limitation that doesn't exist in Win2k. That's why you can't compare them even when running the same software.
Sorry, but it in fact does exist. The NT family OSes instance an USER heap and a GDI heap on a per application basis.
If they did not, they wouldn't be able to run Win 9x/ME applications. So, provided you find a really badly resources leaking application, you'll be able to see it crash, even on Win XP. You'll probably have to write such an app on purpose, however, because AFAIK there is no known app able to do it. But possible it sure is.
QUOTE (dencorso @ Mar 23 2009, 06:35 AM)
...The NT family OSes instance an USER heap and a GDI heap on a per application basis...
So there it is in a nutshell!
To paint a picture:
If the shell in Windows 9x was replaced by a single application and then Windows started, it would be like running an app on a NT OS...
All the resource heaps exclusively available to that app.
There is a significant architectural difference between shared heaps and per app heaps...
QUOTE (Queue @ Mar 20 2009, 01:32 PM)
And dencorso... your system tray is an abomination. ^_^ Mine has two icons, and that's two too-many. The speaker icon (which I leave just so I always have one thing, because truthfully an empty system tray is weird) and ZoneAlarm. The only other thing I have run at startup is TweakUI.
Well, on WinXP I have more than 30 icons in tray
In worst times when I was choosing dictionary and sheduler and was trying several alternatives it was more than 40 icons . Few weeks ago I garbaged my desktop so, there was no place for new icons (32x32 icons, 1280x1024 desktop) And it wasn't on purpose.QUOTE (dencorso @ Mar 20 2009, 12:54 PM)
Of course, I've got many real programs in start-up that do IMHO useful things, like Pop Up Killer 1.45.5, HDDHealth 2.1 and Disk Space Monitor 1.0b4 ... At any moment, from start-up onwards, I have at least 16 icons in the system tray. I've trimmed my start-up configuration to the limit. I can't do without any of the programs in the tray. I need the things they do.
If I may suggest TrayIcon for even further "trimming" of your tray icon numbers, consumes very little resources...It is only a list of shortcuts that loads in the Tray. From there you can start any program/Windows function/screen saver you wish.
Cannnot find it on the net anymore, so here it is...
* TrayIcon v2.5 32-bit for Windows 9x/NT4/2000/ME/XP/2003 creates, modifies, removes + reorders Tray Icons (single-click system Tray shortcuts) for any Windows/DOS program, app, game, screen saver, Windows function etc, changes icons to any valid icon file/library/executable/bitmap, highly customizable:
http://www.mdgx.com/files/TRAYICON.TXT
Direct download [124 KB, uncrippled, no nag shareware]:
http://www.mdgx.com/files/TI25.ZIP
Enjoy.
QUOTE (dencorso @ Mar 19 2009, 12:53 AM)
I've just installed RP9. I did a full install. I am not using any skin, nor 32-bit icons at the moment, but I'm using ClearType. Here're my first impressions:
Before RP9, just after system startup: 57% USER resources & 82% GDI resources.
After RP9, just after system startup: 71% USER resources & 81% GDI resources.
And the resource drain is much slower, and resource recovery (after working for some time and then closing every aplication that was not open just after startup) is much better.
Wow! Wonderful!
Thanks a whole lot Tihiy! Keep on the great work! You rock!
Before RP9, just after system startup: 57% USER resources & 82% GDI resources.
After RP9, just after system startup: 71% USER resources & 81% GDI resources.
And the resource drain is much slower, and resource recovery (after working for some time and then closing every aplication that was not open just after startup) is much better.
Wow!
Wonderful! Thanks a whole lot Tihiy! Keep on the great work! You rock!
Well I am just trying RP9 right now and I don't see any difference at all.
I have tried full install and also minimal install and there is no visible difference that I can see.
But RP9 as a whole does not seem to work at all here I must say.
Maybe that's because I am using Windows ME
QUOTE
Well I am just trying RP9 right now and I don't see any difference at all.
That's the best result i could expect!I'm thinking to revive GDI heap expander i had.
But there had to be a reason for it to be.
The simplest idea idea i half-baked in my expander is to move un-selected GDI objects out of the 16-bit heap. To achieve that, GDI functions are modified in such matter that GDI objects 16-bit data is copied into my 32-bit heap and de-allocated.
When selected, object is allocated back into 16-bit heap and data is moved.
That opens possibility to have virtually unlimited number of unselected GDI objects. In theory.
In practice, most objects can't be moved from 16-bit heap, since they are allocate data in global memory (which is also quite limited), and references to them are stored in other places, like display driver.
But, to the certain extent, this technology can improve GDI usage. For example, in Opera, most graphic data is stored in GDI DIB sections and can be moved and i expect heap expander will greatly improve situation.
But it won't help in other cases. It won't give you power to open myriad of apps.
So is it worth it? Tell me scenarios you lack resources in.
@ Tihiy : The applications I mostly use are : Firefox 1.5.0.1, Azureus 2.5.0.0, ICQ 5.0 and WinAmp 2.91. Sometimes the resources get totally depleted so that closing all apps helps only for a while and restart is unavoidable. In my case, Azureus and Firefox suck all the resources, that is for sure. So a patch would be worth it for me ! 
The resources are the only thing that bugs me about Windows 98 and make me play with the thought migrating to XP ... but Im not a kamikaze.
The resources are the only thing that bugs me about Windows 98 and make me play with the thought migrating to XP ... but Im not a kamikaze.
QUOTE
Firefox 1.5.0.1, Azureus 2.5.0.0
Don't use Azureus. Upgrade Firefox. Use fixed msimg32.dll from kernelex.
The thing is, Tihiy, that RP9 does install and uninstall, but when it is installed it does not seem to work, I mean I can't load a skin for example. Skins are listed (but I don't think displayed properly) in the config panel but selecting one and clicking apply or OK yelds nothing. Same goes for everything else I tried. So I was not sure it was working at all, including your User and GDI optimizations.
And I am not sure I understand why no change in the resource usage is the best you could expect as dencorso seem to have positive results. Maybe you've understood it as my resource usage remaining constant after some use of the OS. If so that's not the case. RP9 is installed but everything seems to behave as if it wasn't there. Maybe that's all off topic here and I should post it in the in the RP9 thread.
As for reviving the GDI expander you had worked on, I think it is certainly a good idea but perhaps without an equivalent User expander it does not make too much sense, as it's the User resources that seem to always be depleted the most here.
You know better anyway if you want to spend time and efforts on that or not. If it's lot of work for at best very little expected results, then there is perhaps no point in it.
I'd be just glad right now if I could get the same boon as dencorso does.
And I am not sure I understand why no change in the resource usage is the best you could expect as dencorso seem to have positive results. Maybe you've understood it as my resource usage remaining constant after some use of the OS. If so that's not the case. RP9 is installed but everything seems to behave as if it wasn't there. Maybe that's all off topic here and I should post it in the in the RP9 thread.
As for reviving the GDI expander you had worked on, I think it is certainly a good idea but perhaps without an equivalent User expander it does not make too much sense, as it's the User resources that seem to always be depleted the most here.
You know better anyway if you want to spend time and efforts on that or not. If it's lot of work for at best very little expected results, then there is perhaps no point in it.
I'd be just glad right now if I could get the same boon as dencorso does.
QUOTE (eidenk @ Mar 28 2009, 12:38 PM)
I have tried full install and also minimal install and there is no visible difference that I can see.
But RP9 as a whole does not seem to work at all here I must say.
Maybe that's because I am using Windows ME
But RP9 as a whole does not seem to work at all here I must say.
Maybe that's because I am using Windows ME
AFAI had understood, RP9 ought to work equally well on 98SE and ME.
BTW, what's the difference between full and minimal? What doesn't get installed in minimal?
QUOTE (Tihiy @ Mar 28 2009, 07:58 PM)
But it won't help in other cases. It won't give you power to open myriad of apps.
So is it worth it? Tell me scenarios you lack resources in.
So is it worth it? Tell me scenarios you lack resources in.
I've got two scenarios, of the critical system resource depletion.
1) The bad flash web contents code does allocate more and more system resources. The same web pages are causing resource depletion on many different browsers. The best defence is to lock the URL the fault causing flash contents is comming from.
2) A faulty application has some sort of a resource draining bug in the report manager function. Every time a certain reports are being created 2-5% of system resources are being locked in Windows 98. However, there are no problem in Windows 2000. I'm suspecting the report manager function has it's own resource table assigned. So, every time it is oppened a new resource table is created. The application manufacturer does not want to deal with this kind of a problem, as they do not want to accept any bug reports with just the Windows 98 in them. The only bug I can report in Windows 2000 is a small memory leak (less than a 100kB locked with every report manager session).
It is enough to run the report manager about 10 times on Windows 98 to get the system unstable, or locked. Appart from the resource leak it does allocate over 40% of the system resources when working, as well. On the other hand, on Windows 2000 the application worked correctly after 500 iterations of the report manager sessions. The only side effect was about 50MB of memory being locked.
In the end all I can do is to tell to the Windows 98 users to close the application after every few reports.
So, in my case, the ability to displace the forgotten resource entries to some other table, would significantly increase the Windows 98 stability.
I guess browsers are generally resource-hungry. In my case, it's SlimBrowser that eats up a lot of resources with each open page and it won't free them when a page (tab) is closed; possibly not freeing all allocated resources even when closed.
Another one for me is the official eMule, which - when open - only allows me either Miranda or SlimBrowser, but not both.
Most likely off-topic, but since I'm here, I'd like to ask if there's anybody else getting "Error: not enough memory" in Nero 7.0.0.0 when trying to burn a DVD (haven't tried CDs) with 512MB of RAM. This is because Nero used to work fine with only 256MB and coincidentally (or not) it started throwing such error right after me upgrading the RAM to 512MB. It does work fine despite that error, but it's annoying having to confirm the message box on each burn.
Tihiy, I'll contact you sometime these days about this GDI heap topic.
Another one for me is the official eMule, which - when open - only allows me either Miranda or SlimBrowser, but not both.
Most likely off-topic, but since I'm here, I'd like to ask if there's anybody else getting "Error: not enough memory" in Nero 7.0.0.0 when trying to burn a DVD (haven't tried CDs) with 512MB of RAM. This is because Nero used to work fine with only 256MB and coincidentally (or not) it started throwing such error right after me upgrading the RAM to 512MB. It does work fine despite that error, but it's annoying having to confirm the message box on each burn.
Tihiy, I'll contact you sometime these days about this GDI heap topic.
QUOTE (Drugwash @ Mar 29 2009, 08:42 AM)
Most likely off-topic, but since I'm here, I'd like to ask if there's anybody else getting "Error: not enough memory" in Nero 7.0.0.0 when trying to burn a DVD (haven't tried CDs) with 512MB of RAM. This is because Nero used to work fine with only 256MB and coincidentally (or not) it started throwing such error right after me upgrading the RAM to 512MB. It does work fine despite that error, but it's annoying having to confirm the message box on each burn.
I never heard of such an error before. But, why not get back to 256 MiB temporarily, just to test whether more RAM is the origin of the problem?
I'm pleased to announce that future Revolutions Pack 9 version will include technology which will greatly reduce USER resource usage in common scenarios. After your reports and my research i found a big hole in USER heap which i'm able to plug.
Hole I found is in the design of list and combo box controls built in USER subsystem which consume a lot of space in 64K heap. The issue is so bad that any application that uses list/combo boxes makes easily noticeable impact. Less than 300 combobox windows can be created on pure system (while global windows limit should be 16000).
To solve this issue, combo and list boxes had to be completely rewritten. That was hard task (on which i worked on for long time), but it's near finishing. 'Beta' version is kinda ready, but there are known compatibility problems and RP9 re-architecting tasks to be done.
Test numbers:
My unscientific 'Load 3 ImgBurn copies' test shows 65% USER free up from 39%.
If you're interested in your scenario, i'm ready to test it.
Hole I found is in the design of list and combo box controls built in USER subsystem which consume a lot of space in 64K heap. The issue is so bad that any application that uses list/combo boxes makes easily noticeable impact. Less than 300 combobox windows can be created on pure system (while global windows limit should be 16000).
To solve this issue, combo and list boxes had to be completely rewritten. That was hard task (on which i worked on for long time), but it's near finishing. 'Beta' version is kinda ready, but there are known compatibility problems and RP9 re-architecting tasks to be done.
Test numbers:
My unscientific 'Load 3 ImgBurn copies' test shows 65% USER free up from 39%.
If you're interested in your scenario, i'm ready to test it.
QUOTE (Tihiy @ May 16 2009, 05:58 AM)
I'm pleased to announce that future Revolutions Pack 9 version will include technology which will greatly reduce USER resource usage in common scenarios. After your reports and my research i found a big hole in USER heap which i'm able to plug.
Is it the "long-secret feature" you mentioned in the RP9 thread?
Will it benefit all programs or just certain kind of programs?
QUOTE
Is it the "long-secret feature" you mentioned in the RP9 thread?
Yes. QUOTE
Will it benefit all programs or just certain kind of programs?
Most GUI programs.
QUOTE (Tihiy @ May 16 2009, 09:48 PM)
QUOTE
Will it benefit all programs or just certain kind of programs?
Most GUI programs.How about web browsers?
QUOTE
How about web browsers?
IE - based ones, for sure. Unlikely for others. Is there browsing scenario which eats a lot of USER (except opening lots and lots of pages)?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.