Jump to content

Detailed information on the GDI resources


egrabrych

Recommended Posts

In Windows 98, it is possible to monitor the amount of the GDI resources in use, using the Resource Meter system tool. The problem is, this tool doesn’t provide information about what (which processes, files, programs) consumes the GDI resources and to what extent. It only provides a statistic. One program that I know – Usage Monitor – also doesn’t provide the detailed information in Windows 98 (despite even displaying a column intended for it). Does anyone know a program/tool which would provide the detailed information when used in Windows 98?

Link to comment
Share on other sites


AFAIK there is no way to do that directly  as the GDI heaps don't store information as to which process owns which used resource if i am not mistaken.

 

The only way you might know is by running a tool such as Bear and check what it reports before and after running a program.

Link to comment
Share on other sites

That’s too bad. :(  I had hopes for something like constant monitoring of the allocation of GDI resources, the same way Process Explorer enables to do with the allocation of CPU resources. Now I understand why there is an empty column in Usage Monitor’s report.

 

Thanks for your answer!

Link to comment
Share on other sites

There used to be an old package called 'Leaks' if I'm not mistaken, which can display GDI usage before and after running a certain application.

It contains 'GDI Usage' and 'Menu Usage' - two separate executables. The first one says 'Should help you find GDI leaks / by Christophe' in the 'About' box (right-click the application titlebar -> About GDIUsage).

It does not provide real-time statistics, however it may help finding out which application uses many GDI object, what type of objects and if there are any leaks in it, by clicking 'Compare!' after the applicaiton is closed.

 

Hopefully someone here has a working download link at hand, otherwise I could try to find the archive on my drives/CDs and put it on my cloud.

Link to comment
Share on other sites

I know Bear and it doesn't do what GDIUsage does. It actually lists the elements by handle and displays the loaded bitmaps, brushes, fonts, memory DCs, palettes, pens and regions when selected in the list. This allows the user to recognize the elements and tell whom they belong to. This is gold, compared to Bear. ;)

 

Eventually I found the Leaks package. But it's not in its rightful place anymore. The Wayback Machine used to host a viable page with an active download link, but I guess the "good guys" at M$ got to them - no download link on the archived page copies. See here, for example.

 

There is an alternative location where the package can be found, but after downloading and also searching my 98SE machine, I realized it always was the code, not the executables. Looking in my freeware code folder, I found the three projects - I had compiled them myself on April 9th 2012.

 

Now, since the code has been freely available some time ago at MSDN and I compiled it myself, I guess it wouldn't be a problem to share the executables, would it? If nobody says otherwise, I'll upload them to my cloud and link them here somewhere.

 

EDIT: Uploaded executables and original sources in the Leaks folder (see my signature). Let me know if there's any problem.

Edited by Drugwash
Link to comment
Share on other sites

I apologize for not responding for so long.

 

So, to put things in order:

  • Bear program (jaclaz – thanks for the link :)) does indeed display the list of elements  that Drugwash wrote about - but in Windows XP:

post-293708-0-06726600-1425130082_thumb.

 

in Windows 98 it only provides synthetic numerical data:

 

post-293708-0-97465700-1425130092_thumb.

 

– as it is said on this site: http://thesz.diecru.eu/content/bear.php

It is the case both when it comes to the current 1.52 version of Bear and to the version 1.42 which is  available through Wayback Machine (and 1.14, as shown on the screenshots).

 

 from the MSDN website: https://msdn.microsoft.com/en-us/magazine/cc188782.aspx

However, I downloaded the content of Leaks folder from Drugwash (thanks :)). GDI Usage (one of the three applications in this folder), after clicking [Details], shows in a new window individual GDI objects:

 

post-293708-0-98666100-1425130104_thumb.

 

                                   due to their often characteristic appearance, you can guess where they come from.

 

GDI Usage only works under Windows 9x (for Windows 2000 and XP there is a different  application, available in the same folder: GDI Count).

 

  • For Windows 98, I think that GDI Usage is more appropriate than Bear. It may provide only incomplete and unspecified information, but in most cases this should be enough to identify the cause of losing free GDI resources. A different matter is what to do with the problem once we have identified it using GDI Usage (usually, it concerns a program we have no influence on) – but this matter goes beyond the thread’s subject. Once again, I thank everyone for help and advice :yes:.
Link to comment
Share on other sites

I don't know if the info displayed by Norton System Information is what is being sought here, but this is what I see. Under Memory General Information tells me I have 81% free 16-bit User and 93% free 16-bit GDI:

post-357900-0-08135900-1425139586_thumb.

If I expand 16-bit system applications, I have only 2 of those (mmtask and msgsrv32). If I fully expand msgsrv32, this is what I get:

post-357900-0-71006600-1425139652_thumb.

If I expand the 16-bit libraries, there are many entries. If I expand the first one (avicap) I get this:

post-357900-0-46775200-1425139679_thumb.

If I expand 16-bit applications, I have 3 items. If I fully expand the first one, I get:

post-357900-0-61651100-1425139710_thumb.

If I expand 16-bit system libraries, there are about 2-dozen of them. If I expand the first one (comm) I get this:

post-357900-0-65187300-1425139739_thumb.

I assume that it's the 16-bit items that cause GDI resource issues for win-98. ?

Link to comment
Share on other sites

Yes, it's the small size, along with leaks, of 16bit resource segments (USER and GDI) that are the reason resources get depleted. It's been discussed quite a bit a while back. Try to look into old topics for more information. Searching for "heap expander" would probably yeld. Having Revolution Pack installed can mitigate the GDI depetion issues to some degree as it's got a built-in clean-up routine for those, not so much for the USER resources unfortunately.

Edited by loblo
Link to comment
Share on other sites

While you are at it, check also this "Veign's Usage Monitor".

 

Here is an old version:

https://web.archive.org/web/20080316005020/http://www.veign.com/application.php?appid=110

 

In Windows 98, it is possible to monitor the amount of the GDI resources in use, using the Resource Meter system tool. The problem is, this tool doesn’t provide information about what (which processes, files, programs) consumes the GDI resources and to what extent. One program that I know – Usage Monitoralso doesn’t provide the detailed information in Windows 98 (despite even displaying a column intended for it).

 

This also applies to the older version Usage Monitor.

 

 

 

I have reuploaded  the super hard to find GDIView from tihiy to add one more to the pile: http://www.datafilehost.com/d/1ea1abfc

 

Good :), and I am attaching it to this post, so that it doesn't get lost.

jaclaz

 

It works similarly to GDI Usage, but I like less.

Edited by egrabrych
Link to comment
Share on other sites

Yes, it's the small size, along with leaks, of 16bit resource segments (USER and GDI) that are the reason resources get depleted. It's been discussed quite a bit a while back. Try to look into old topics for more information. Searching for "heap expander" would probably yeld. Having Revolution Pack installed can mitigate the GDI depetion issues to some degree as it's got a built-in clean-up routine for those, not so much for the USER resources unfortunately.

 

http://www.msfn.org/board/topic/136171-gdi-heap-extender/

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...