Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.Login to AccountCreate an Account

Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

uxtheme.dll substitute

jds

Posted 03 August 2012 - 02:19 AM

jds

-DOS+

Member

603 posts

Joined 03-June 08

OS:98SE

Country:

I came across this interesting and potentially useful extension, a substitute for 'uxtheme.dll' which was introduced in XP. It's actually built from Wine sources, intended to fill the same hole in W2000, but according to Dependency Walker, it's fine for W98 too :

jumper

Posted 03 August 2012 - 04:17 AM

jumper

2015 All-American Masters HJ'er

Member

539 posts

Joined 21-January 11

OS:98SE

Country:

Good find, Joe.

Tapping into the on-going Wine development will be key to playing catch-up to new MS API's.

ReactOS has a later Win32 build of uxtheme.dll that is probably also based on the Wine sources, but it has heavy dependencies on newer system API's as well. Other versions of uxtheme.dll that I've found are only stubs or very limited implementations.

For DLL's that don't exist in 9x, we should be able to build with Mingw compatible versions from the latest Wine sources using the instructions in your linked article.

For DLL's that do, we can build full or partial (just the needed API's) DLL's and modify in core.ini the KernelEx compatibility modes to invoke them as needed. This would require some extra (Kext) code in each DLL, or the use of Kexstubs API forwarding. For non-KernelEx users, RLoew's API hook tool could be used instead.

rloew

Posted 03 August 2012 - 09:40 AM

rloew

MSFN Expert

Member

1,136 posts

Joined 30-May 05

OS:98SE

Country:

For DLL's that do, we can build full or partial (just the needed API's) DLL's and modify in core.ini the KernelEx compatibility modes to invoke them as needed. This would require some extra (Kext) code in each DLL, or the use of Kexstubs API forwarding. For non-KernelEx users, RLoew's API hook tool could be used instead.

My API Hook Tool DLLHOOK has been updated to support KernelEx 4.5.2. I have been developing a KernelEx specific addon called KEXEX that contains a DLL with functions I have implemented and an .INI File with redirects for these functions and numerous others that have to be forwarded to new names and/or Modules.

Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

loblo

Posted 03 August 2012 - 10:49 AM

jumper

Posted 03 August 2012 - 09:40 PM

jumper

2015 All-American Masters HJ'er

Member

539 posts

Joined 21-January 11

OS:98SE

Country:

BlackWingCat's kdw and KernelEx only offer stubs and limited support for Uxtheme. That may be enough for now, as 9x doesn't seem to contain the infrastructure to really support much more yet. But ideally we'd like to have a complete implementation for when all the other pieces fall into place.

For weeks I've been researching projects that might be helpful in extending KernelEx once API forwarding was functional. Until last night I hadn't really focused on Uxtheme, however. Here are some options:

Would it be difficult to add them in the future version, especially the ones which have sth to do with ActCtx, i.e. ActivateActCtx, CreateActCtxA, CreateActCtxW, DeactivateActCtx & ReleaseActCtx? They help fix a lot of dependencies and also make it possible to use uxtheme.dll directly from %systemroot%\system32. Without these dependencies there are problems with .NET Framework (when uxtheme.dll is present in the system, that is).

Uxtheme causes .NET problems on Win2K:

I've removed KB908536.

Uxtheme.dll seems to cause problems with .NET Framework based applications. I tried both versions - one from OldCigarette and the other one from BlackWingCat but unfortunately it's always the same. There's an error when trying to launch .NET based programs.

Would it be difficult to add them in the future version, especially the ones which have sth to do with ActCtx, i.e. ActivateActCtx, CreateActCtxA, CreateActCtxW, DeactivateActCtx & ReleaseActCtx? They help fix a lot of dependencies and also make it possible to use uxtheme.dll directly from %systemroot%\system32. Without these dependencies there are problems with .NET Framework (when uxtheme.dll is present in the system, that is).

Uxtheme causes .NET problems on Win2K:

I've removed KB908536.

Uxtheme.dll seems to cause problems with .NET Framework based applications. I tried both versions - one from OldCigarette and the other one from BlackWingCat but unfortunately it's always the same. There's an error when trying to launch .NET based programs.

Yeah, I saw some of these issues mentioned in regards the alternative 'uxtheme.dll' files from some of the unofficial W2000 updates, which is why I looked further afield.

The only dotNet application I use (that I'm aware of) is the command line "odfconverter" utility. This seems to be functioning normally after installing the Wine-derived 'uxtheme.dll' file (and 'libwine.dll') in the 'system' directory. Also, the "netfx_setupverifier" utility says my dotNet (2.0) installation is still OK.

loblo

Posted 06 August 2012 - 04:36 AM

loblo

Oldbie

Member

801 posts

Joined 12-January 10

OS:ME

Country:

BlackWingCat's kdw and KernelEx only offer stubs and limited support for Uxtheme. That may be enough for now, as 9x doesn't seem to contain the infrastructure to really support much more yet. But ideally we'd like to have a complete implementation for when all the other pieces fall into place.

So I take it you'd like to implement full XP theming support in 98/ME but I personally think there is no point to it since it's not something that's going to make more recent programs run on our systems.

loblo

Posted 06 August 2012 - 04:52 AM

loblo

Oldbie

Member

801 posts

Joined 12-January 10

OS:ME

Country:

The only dotNet application I use (that I'm aware of) is the command line "odfconverter" utility. This seems to be functioning normally after installing the Wine-derived 'uxtheme.dll' file (and 'libwine.dll') in the 'system' directory. Also, the "netfx_setupverifier" utility says my dotNet (2.0) installation is still OK.

Well that's not surprising since that application is not dependent on uxtheme.dll...

Btw guys, it's possible to run quite a few dotnet 3.0/3.5 applications by getting the missing assemblies they may depend on from dotnet 3.5 installer and putting them in the system dir or the application folder. Remotesoft .NET Explorer is a good free tool for identifying missing .net dependencies. The WPF files won't work but often it's only just system.core.dll that's missing and this one runs just fine. I have tried hard to get some net 4.0 apps to run but to no avail even the simplest ones.

tomasz86

Posted 06 August 2012 - 05:06 AM

tomasz86

www.windows2000.tk

Member

2,528 posts

Joined 27-November 10

OS:none specified

Country:

Actually the problem with .NET Framework 2.0 and uxtheme.dll doesn't affect only the applications which use uxtheme.dll itself. I think the core of the problem is that .NET Framework 2.0 "thinks" that the OS is XP/2003 when uxtheme.dll is present in %windir%\system32 and calls for APIs which don't exist in Windows older than XP. Programs which simply need .NET Framework 2.0 files to be present in the system will probably work anyway but if they really use some of the .NET functions and call for them then the issue will occur.

jds

Posted 09 August 2012 - 03:13 AM

jds

-DOS+

Member

603 posts

Joined 03-June 08

OS:98SE

Country:

Btw guys, it's possible to run quite a few dotnet 3.0/3.5 applications by getting the missing assemblies they may depend on from dotnet 3.5 installer and putting them in the system dir or the application folder.

loblo

Posted 11 August 2012 - 12:26 PM

loblo

Oldbie

Member

801 posts

Joined 12-January 10

OS:ME

Country:

Btw guys, it's possible to run quite a few dotnet 3.0/3.5 applications by getting the missing assemblies they may depend on from dotnet 3.5 installer and putting them in the system dir or the application folder.

Hey, that's great news, loblo.

Are you able to give a little more details on the process?

Joe.

I am not sure what more details I can give about that however I can say that the difficulty lies in determining whether a dotnet app which doesn't start has missing dependencies and which ones as the usual tool, dependency walker isn't useful and that's why I mentioned the Remotesoft .NET Explorer (which runs as a standalone program) as it allows to determine that, although not as straightforwardly as dependency walker does for non dotnet apps.

jds

Posted 20 August 2012 - 08:14 AM

jds

-DOS+

Member

603 posts

Joined 03-June 08

OS:98SE

Country:

I am not sure what more details I can give

Well, I started looking at this by extracting the dotNet 3 installer contents with 7-Zip. That resulted in a reasonably large bunch of files to sift through. So I deleted all the localized versions of the various files, which was about half of them, then all the files that had "setup" in their name or within their Version information, similarly any download related files, then anything else that didn't look useful. In the end, I had no files left.

So it's not clear to me at all where are these "missing assemblies" that you mention within the dotNet 3 installer. If it's a file called 'system.core.dll', well this wasn't present in the stuff extracted by 7-Zip. BTW, I also don't know what is a "WPF" file, I presume it's not a Wordperfect Form?

I don't think I would be alone in needing an extra little clue or two to get started with this dotNet 3.X stuff.

I did google WPF, and the half dozen hits I opened all said about that Wordperfect stuff. That's why I asked.

As for the two dotNet installers I have, "dotnetfx3setup.exe" and "dotnetfx35setup.exe", neither of them have a "wcu" directory, etc. Hence my confusion. I'll download "dotnetfx35SP1.exe" and check it out.

Thanks again, guys.

Joe.

PS. I've now downloaded 3.5SP1 from MS under the file name "dotnetfx35.exe". It's huge, about 10 times bigger than the 2.0 framework, and almost 100 times bigger than the two 3.0 and 3.5 installer packages I'd previously downloaded. In retrospect, it's now obvious that the files I had previously downloaded from MS were just downloaders, not the real dotNet packages.