[MDGx]

 

This post has been edited by MDGx: 14 February 2006 - 01:41 AM

[eidenk]

I have actually stopped using it as I was sometimes getting terminal GDI crashes in image editing programs when resources were still abundant enough. I haven't switched back to the official one that I did not use before testing this one so I can't say if those problems were U891711 specific or if they arise as well with MS KB891711 v2.

[bristols]

eidenk, on Dec 1 2005, 04:12 AM, said:

I have actually stopped using it as I was sometimes getting terminal GDI crashes in image editing programs when resources were still abundant enough. I haven't switched back to the official one that I did not use before testing this one so I can't say if those problems were U891711 specific or if they arise as well with MS KB891711 v2.

Hopefully the crashes had nothing to do with U891711 specifically. But still, it's a pity that your crashes were not experienced, or otherwise mentioned, until now.

Again, hopefully (and for all I know, in all likelihood) U891711 is fine (it's still good for me) - especially because now it's a part of Gape's Service Pack.

This post has been edited by bristols: 30 November 2005 - 11:16 PM

[eidenk]

It's easy enough to disable it from running if one were to experience such problems which, I must say, were far from systematic but didn't arise again since I am not using it anymore. I could be trying instead to run KB891711 to see if it also sometimes happens but I don't like that hotfix so I won't personally be running neither of them, official or unnoficial.

[MDGx]

I have also been experiencing random crashes with image/icon editing programs, with both official + unofficial 891711 patches.
So I figured out those errors were not related to any of those patches, but to the way they both affect the LoadImage function.

So now that U891711 [to my knowledge] turned out to be a better and less buggy patch, I have uninstalled them all for good.

Hope this helps.

[MDGx]

U891711 update:

Author's note:

Quote

KB891711.EXE and Q891711.DLL do not use any GDI functions or GDI objects.
Therefore, it is highly unlikely that any image/icon editing tools crashes are
caused directly by any of the unofficial or official versions. Nor would I
expect the changes in the 'LoadImage' function to be the direct cause. GDI.EXE
(all Win98 + WinME versions) has serious bugs that often lead to heap
corruption when GDI resources drop below 10%. However, this corruption may
manifest itself only much, much later when GDI resource levels are again
higher or even at more than 70%.

This post has been edited by MDGx: 02 December 2005 - 10:51 PM

[eidenk]

All I can say is that I never experience a GDI crash with any of the many image editing programs I use except sometimes when I run this patch.

I use my computer enough to be able to assess that.

On my system (WinME) I get GDI crashes only when I try to go below 0% but this affects all standard applications of course. I have been testing stability in this respect by running scores of applications until reaching 1 or 2% of free resources left. The system remains rock stable. Closing most of the apps then frees most of the resources and the system never GDI crashed afterwards.

If I recall well, some GDI stability problems already begin to arise on Win98SE below 30%. Maybe what is written above by the U891711 author applies to Win98SE but certainly not to WinME which has apparently benefited from great improvement in this respect.

What I am interested in, with respect to resources, is whether the possibilty exist to increase the size of the available resources by hacking/patching certain system files and have, say, the double to start with, which would allow to run more applications at once without falling in the red.

[erpdude8]

eidenk, on Dec 3 2005, 12:04 AM, said:

All I can say is that I never experience a GDI crash with any of the many image editing programs I use except sometimes when I run this patch.

I use my computer enough to be able to assess that.

On my system (WinME) I get GDI crashes only when I try to go below 0% but this affects all standard applications of course. I have been testing stability in this respect by running scores of applications until reaching 1 or 2% of free resources left. The system remains rock stable. Closing most of the apps then frees most of the resources and the system never GDI crashed afterwards.

If I recall well, some GDI stability problems already begin to arise on Win98SE below 30%. Maybe what is written above by the U891711 author applies to Win98SE but certainly not to WinME which has apparently benefited from great improvement in this respect.

What I am interested in, with respect to resources, is whether the possibilty exist to increase the size of the available resources by hacking/patching certain system files and have, say, the double to start with, which would allow to run more applications at once without falling in the red.

I have a HP pavilion machine with pre-installed ME, I used to have those GDI problems several years ago. I just got rid of the apps that have caused those GDI crashes; some apps I have upgraded to reduce the chances of the GDI problems from happening. I no longer have those GDI problems anymore, regardless whether I had the U891711 patch or not. it's usually those 3rd party apps that arent written well and more likely to cause those GDI crashes.

[MDGx]

eidenk:

Here's U891711 author's answer to your comments:

Quote

I am afraid the brief answer to 'eidenk's' question is: virtually
impossible w/o a major revamp of GDI.EXE. More details below.

------------------------------------------

'eidenk' wrote:

All I can say is that I never experience a GDI crash with any of the many
image editing programs I use except sometimes when I run this patch.

I use my computer enough to be able to assess that.

On my system (WinME) I get GDI crashes only when I try to go below 0% but
this affects all standard applications of course. I have been testing
stability in this respect by running scores of applications until reaching
1 or 2% of free resources left. The system remains rock stable. Closing
most of the apps then frees most of the resources and the system never GDI
crashed afterwards.

If I recall well, some GDI stability problems already begin to arise on
Win98SE below 30%. Maybe what is written above by the U891711 author
applies to Win98SE but certainly not to WinME which has apparently
benefited from great improvement in this respect.

What I am interested in, with respect to resources, is whether the
possibilty exist to increase the size of the available resources by
hacking/patching certain system files and have, say, the double to start
with, which would allow to run more applications at once without falling
in the red.

--

The amount of GDI resources is largely determined by the GDI 16-bit data
segment. This 16-bit segment is limited to 64 KByte. Unfortunately, there
is no easy way to increase it as a 16-bit offset can only address 65536
bytes max. GDI.EXE 4.90.3000 has fewer bugs and is far more stable than,
for example, 4.10.2225, but it still is very buggy. Fatal GDI heap
corruption shows up mainly in three ways, (1) a GPF in GDI.EXE, (2) a GPF
in USER.EXE, and (3) a BSOD in KERNEL32.DLL (address depends on the
version of KERNEL32.DLL). Depending on the system configuration, (3) &
even (2) may happen more often than (1). Before fatal heap corruption
occurs, some GDI objects may not have been used and/or freed properly (in
particular, when resource levels drop below 10% - even with 4.90.3000!)
and the system may still appear 'rock solid', may never crash or may only
crash when the system is shut down.

Please post original crash error messages if you have them. I have not had
any real GDI.EXE crash in a long, long time and it did not change after I
installed KB891711.EXE 4.10.2222. What I suspect here is the following:
'LoadImage' is called thousands of times by most applications and the
system itself and so is the code in KB891711.EXE/Q891711.DLL. This may
trigger some bug in the 16-bit subsystem, a bug that is there all the
time, but is almost never triggered unless KB891711.EXE is running. For
example, KB891711.EXE allocates and releases additional GlobalMemory
through the 16-bit subsystem (KRNL386.EXE) whenever 'LoadImage' is called.

Hope this helps.

[eidenk]

Quote

Please post original crash error messages if you have them.

Unfortunately I did not make note of them but I will run the patch again and will post them if those occasional GDI crashes arise again.

If I understand you well, the GDI resources are exclusively 16bits. Have you got any knowledge of the 32bits part of the resources, which may not be GDI but USER and SYSTEM. I understand that the 32bits resources are of an arbitrary size far below their theoretical limit unlike 16bits ones and that it should be eventually possible to set a larger amount of memory for them quite easily for someone who's got the knowledge of those inner workings.

[MDGx]

eidenk:

The answer from the author:

Quote

'eidenk' wrote:

Unfortunately I did not make note of them but I will run the patch again
and will post them if those occasional GDI crashes arise again.

If I understand you well, the GDI resources are exclusively 16bits. Have
you got any knowledge of the 32bits part of the resources, which may not
be GDI but USER and SYSTEM. I understand that the 32bits resources are of
an arbitrary size far below their theoretical limit unlike 16bits ones and
that it should be eventually possible to set a larger amount of memory for
them quite easily for someone who's got the knowledge of those inner
workings.

--

TWEAKUI.CPL has a setting that turns on 'fault logging' - very useful for
that. I also start DrWatson.exe at boot-up time whenever I use Win98SE
(occasionally these days, it is mostly WinXP SP2 now).

Unfortunately, the answer is: not possible. GDI resources are from a
"combined" 16-bit and 32-bit heap in the GDI data segment. The 16-bit heap
is the real bottleneck. It is the same situation with USER resources, it
is just a different 16-bit/32-bit heap in the USER data segment. The level
of system resources is the lower value of either GDI or USER resources,
but not another heap.

This post has been edited by MDGx: 16 December 2005 - 10:37 PM

[mamas6667]

I've tried the official one old and new
Tihiy's TI891711
and now U891711
I'm sure U891711 is better than MSN's
But it still slows my system down(less responsive).
I think is the fact that KB891711.exe is running as a service(always)

Tihiy's TI891711 doesn't run KB891711.exe upon bootup.

So i will continue to use use Tihiy's TI891711, I'm a gamer and I need the resources.

PIII 450MHz 256MB
WIN 98SE, sesp21a-en.exe, 98SE2ME.EXE(ver 3.7), TI891711, 98KRNLUP.EXE

[erpdude8]

mamas6667, on Dec 9 2005, 09:34 AM, said:

I've tried the official one old and new
Tihiy's TI891711
and now U891711
I'm sure U891711 is better than MSN's
But it still slows my system down(less responsive).
I think is the fact that KB891711.exe is running as a service(always)

Tihiy's TI891711 doesn't run KB891711.exe upon bootup.

So i will continue to use use Tihiy's TI891711, I'm a gamer and I need the resources.

true that TI891711 doesnt load a startup but TI891711 has weaker protection than U891711.

Quote from author of U891711:

----
"Tihiy's TI891711 is a nice piece of work, but, unfortunately, is no real
replacement since it offers only limited protection. 16-bit programs
including USER.EXE (!) can load animated cursor files, etc, and they
bypass TI891711.DLL completely, that is, there is zero protection."
----

The U891711 patch only slowed down my Win98 & ME computers slightly. So I didnt
noticed much of a performance drop with U891711.

[erpdude8]

erpdude8, on Dec 10 2005, 05:52 AM, said:

The U891711 patch only slowed down my Win98 & ME computers slightly. So I didnt
noticed much of a performance drop with U891711.

the w98 machine I used was a pentium one [100 mhz] w/ 64 megs of ram
and the ME machine was a pentium 3 [766mhz] w/ 256 megs of ram

this was assuming I did NOT have any antivirus software installed or loaded at startup.
firewall & antivirus utilities gobble up more resources than U891711

This post has been edited by erpdude8: 12 December 2005 - 01:23 PM

[mamas6667]

Sorry to insist on using Tihiy's TI891711 patch, but playing online games(tactical ops, unreal tournament, etc..) I did notice a significant performance drop with U891711 and MSN was worst.
Also windows reaction time is slower, startup too.

The question now is what security risk am I in using TI891711 patch (will i get infected with viri)
"bypass TI891711.DLL completely, that is, there is zero protection."

PLS explain further, if u find some time!

[MDGx]

mamas6667, on Dec 14 2005, 04:34 PM, said:

Sorry to insist on using Tihiy's TI891711 patch, but playing online games(tactical ops, unreal tournament, etc..) I did notice a significant performance drop with U891711 and MSN was worst.
Also windows reaction time is slower, startup too.

The question now is what security risk am I in using TI891711 patch (will i get infected with viri)
"bypass TI891711.DLL completely, that is, there is zero protection."

PLS explain further, if u find some time!

The difference between U891711 and Tihiy's TI891711 patch is explained in U891711.TXT [see "AUTHOR'S NOTES" = NOTE #1]:
http://www.mdgx.com/files/U891711.TXT

Hope this helps.

[Acheron]

Sorry I haven't tested this fix yet, but I have an important question.

Can anyone tell if KB891711.exe shows up in the Task list after pressing CTRL-ALT-DEL, using this patch?

It's important for me to have it hidden, so people won't kill it accidently and getting BSOD's.

[bristols]

hp38guser, on Dec 15 2005, 11:13 PM, said:

Can anyone tell if KB891711.exe shows up in the Task list after pressing CTRL-ALT-DEL, using this patch?

Nope, it doesn't show up in the Windows Task List window.

[eidenk]

Quote

DEMO
Proof-of-concept example demo of malformed animated cursor [.ANI]using 'LoadImage':
http://www.xfocus.net/flashsky/icoExp/
This applies *only* to Microsoft Internet Explorer 5.5 SP2 and newer:
http://www.mdgx.com/toy.htm#IEX
First try demo above without any update/patch/fix installed.
Then install official MS05-002 fix, reboot, and try the demo again.
Then install unofficial U891711 fix, reboot, and try the demo again.
Please notice differences in behavior between these 2 fixes.

http://www.mdgx.com/files/U891711.TXT

Can someone please explain what exactly the vulnerability is ? As clicking on any of the flashsky links with IE 5.5SP2 on WinME and without a patch running does not make me feel vulnerable to anything, really. If clicking on one of the link would, say, launch Notepad, I'd be scared.

[PsycoUnc]

-yes, I'd like a better demo, as well... it's a bit confusing to me, too...
(-there was one other test website, which was able to freeze up every Firefox window, with 100% cpu... which was annoying, but not a security threat...) ?