Modifying/Replacing Shell32.DLL on NT 4.0

[ironman14]

Hello,

I have noticed that there is KernelEx for 95/98/ME, and UURollup for Windows 2000. But, there is nothing like that for NT 4.0.

So, I tested a few somewhat 'modern' programs (like newer Flash 9, VLC 0.9/1.0, FF3).

I have found that these programs are missing functions in DLL files, which forbid them from running.

I started with VLC 0.9.2, which complained of a missing libvlc.dll file. After locating it and adding it to the VLC folder in the Program Files section,I started the VLC.EXE file and got the error message:

"The procedure entry point SHGetFolderPathW could not be located in the dynamic link library SHELL32.DLL".

I opened this up in Dependency Walker, and goind that that was the sole missing function.

I know that shell32.dll 5.0 (win2k version) introduced SHGetFolderPathW. I obtained that file from a legit source, not an online site. So, I tried copying the 2k shell32.dll file over to the system32 folder, but it didn't allow it. It didn't even allow me to rename the NT 4.0 shell32.dll to shell32.old.dll.

So, I started thinking of an alternative method to add this file. I had heard of cmd, but NT 4.0 has the DOS prompt, which to me makes no sense since NT 4.0 is clearly an NT based Windows, not DOS based. Clearly I would need more 2K DLLs than shell32, but I figure once this is done, I should have no problems with other files.

So, could anyone please tell me how to add the 2k Shell32.dll file to the NT 4.0 system32 directory? Or, please tell me, if possible, how to add SHGetFolderPathW to Shell32.dll 4.72? Thank you very much.

[Tripredacus]

Does ProcMon work on that OS? In my experience, you can use ProcMon to determine the search order for files that a particular program is looking for. It may not work for shell32.dll, since the dependent file may try looking at an absolute path. But if you are lucky it will look somewhere else first. The typical first location for a dependent file is in the same folder that the EXE is in. You can try putting the win2k file in there instead.

[ironman14]

I am not sure about Process Monitor, but I know Process Explorer has some versions that work on NT 4.0. I could look at Process Explorer, assuming that the 2 programs are similar.

[submix8c]

To keep this Topic "connected" -

http://www.msfn.org/board/topic/170603-flash-9-not-working-on-nt-40-consolidated-thread/

You're going to have to consider the -possibility- that not many people bothered with NT4 since Win2K came out, the same as Win95 kind of got left alone in lieu of Win98/98SE/ME. In both cases, the latter "older" OS appeared to be more stable. Also note the Kex Project.

LoneCrusader has done extensive work on Win95OSR2.x (for personal reasons). There's also a Topic on what Software works on 98SE - http://www.msfn.org/board/topic/105936-last-versions-of-software-for-windows-98se/

Generally speaking Win2K is a Pre-Cursor to XP, so it's possible (in some cases) to "trick" 2K into using XP stuff, same as (sometimes) possible to install Drivers from Win7/8 into Vista (and vice-versa).

You may be treading on New Ground.

(Comments above are JFYI and AFAIK...)

It appears that you've been trying (in all of your started and commented-in Topics that you -want- to install Newer(ish) Software on an OS that maybe.just.won't.do.it...

edit - REALLY, dude???

https://forum.videolan.org/viewtopic.php?f=14&t=47897

edit2 - This "claims" 0.9.x/1.0.x -

https://wiki.videolan.org/VSG:Usage:Version/

Still looking for HOW it worked...

Followup - here you are again...

https://forum.videolan.org/viewtopic.php?f=14&t=116117

This guy must be mistaken - V4 is right there in IE4SHLNT.CAB. There must be some kind of "tricK" someone used and isn't telling.

Edit3 - this is "odd" information (with your particular message) -

http://www.keil.com/support/docs/2863.htm

(err, um NO! this is for SPECIALfolderpath)

Edited January 22, 2014 by submix8c

[jaclaz]

There is a documented "tweak" for 2K by FdV:

http://www.msfn.org/board/topic/138242-nt4-explorer-on-xp/

which I believe is "the opposite" of what you are looking for, but that maybe contains some relevant info for your scope as well.

NT4, like *any* NT system has NOT a "DOS", it uses CMD.EXE (and NOT COMMAND.COM) as command processor.

The NT4 version of course misses quite a few functions of newer versions of CMD.EXE (and a few environment variables, including dynamic ones were introduced only in Win 2000, if I recall correctly).

jaclaz

[submix8c]

Not necessarily O/T -

I had menntioned KernelEX (versions are -ONLY good for Win98+ and Win2k to run XP stuff on them). Seems there isn't a version for NT4. As I said "new ground".

In addition, I found a reference to 'SHFolder.dll' that may be doing the actuall Call to "shell32.dll".

See this as a reference to said Function - http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx

I will NOT swear to this but I THINK (probably wrongly) that Kex "redirects" calls "elsewhere"?

It would be really nice to get the "call sequence" as suggested above...

(Just assisting in finding references etc since I have no time to work w/NT4 ATM... sorry...)

edit - FWIW, first VideoLan link in my prior post says by a VLC DEVELOPER in response to you!!! I think you may be barking up the wrong tree.

Can't seem to insert AFTER the following quote, so here you go - scroll down to A2 - definitely the WRONG TREE!

http://msdn.microsoft.com/en-us/library/ms954149.aspx

IOW, replacing/"patching" SHELL32.DLL will NOT fix it!

Jean-Baptiste Kempf » Sat Dec 28, 2013 12:59 pm

It was never tested, because noone cared? That simple.

Edited January 22, 2014 by submix8c

[jumper]

Shell32vlc.7z

Shell32vlc.dll is a wrapper that forwards three calls as needed (by VLC 1.1.10):

LIBRARY   Shell32vlcEXPORTS CommandLineToArgvW	= SHELL32.CommandLineToArgvW SHGetFolderPathW	= SHFOLDER.SHGetFolderPathW ShellExecuteW		= SHELL32.ShellExecuteW

Place in app folder and use in one of two ways:

1) rename to Shell32.vlc and use ImportPatcher or a hex editor to change PE references from Shell32.dll to Shell32.vlc in files that need SHGetFolderPathW

2) rename to Shell32.dll and use RegEdit to delete or rename the SHELL32 entry in KnownDLLs (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs)

Edit: Method #2 won't work with this version of the wrapper because Shell32.dll can't forward to Shell32.dll!

Edited January 26, 2014 by jumper

[ironman14]

Thank you for the link, jumper.

However some of your message wasn't entirely clear to me.

I installed ImportPatcher, then analysed the dependencies of the "current" Shell32.vlc file. It already said in the PE reference that it was Shell32.vlc (it said the file location), so I saw no reason to change it.

I then attempted to use ImportPatcher on the vlc.exe itself, and never saw the name "Shell32.dll" once.(I saw other dlls that were repeated, such as ntdll.dll,gdi32.dll,Kernel32.dll)

Maybe I'm doing something wrong.

I would upload the files, but I am having problems with that.

[jumper]

I downloaded VLC 0.9.2 for testing and that build seems to be unstable (no GUI). Please try another.

The last of each line is usually the most stable, so I recommend trying:

1) 0.8.6i

2) 0.9.8a

3) 1.0.5

4) 1.1.11

Method #1 should work with all of these builds.

Edit: Method #1 (not #2) must be used.

Edited January 26, 2014 by jumper

[ironman14]

I know you just explained this to me, but I am unfortunately still confused.

When I use importPatcher on the Shell32.vlc, it asks me to edit the parameters in a log file,shell3# that it makes. There is a section in there that says:

Portable Executable: C:\Program Files\VideoLAN\Vlc\shell32.vlc.

I assumed that this means that everything is done already, but clearly I'm missing a step, since when I do nothing and save the .log file, nothing happens.

Edited January 27, 2014 by ironman14

[jumper]

1) Do not use anything on Shell32.vlc!

2) Use a hex editor on any EXE or DLL files that invoke SHGetFolderPathW to change "SHELL32.DLL" to "SHELL32.VLC".

ImportPatcher makes it easy to patch Import function names by editing the resulting INI file. Patching Import DLL names is possible, but more difficult. Use a hex editor instead.

P.S. What version of VLC are you working with now?

Edited January 27, 2014 by jumper

[jumper]

Getting back to your title question, here's one way to do it:

1) Rename the W2K Shell32.dll to Shell32.w2k

2) Put it in the System32 folder

3) In RegEdit, use KnownDLLs to redirect "SHELL32" from "Shell32.dll" to "Shell32.w2k"

(See http://support.microsoft.com/kb/164501)

4) Shell32.dll is not shared, so without rebooting launch VLC to test

5) undo step 3 or reboot to make change permanent

Warning: Be aware that if the replacement DLL isn't 100% compatibile, NT4 may not boot!

[ironman14]

I don't have time to look at this now, but thanks for your responses. I will look at it tomorrow.

What do you mean by 100% compatible? Do ALL the functions have to be present in both DLLs (the 2k & NT 4.0)?

[CharlotteTheHarlot]

I don't have time to look at this now, but thanks for your responses. I will look at it tomorrow.

What do you mean by 100% compatible? Do ALL the functions have to be present in both DLLs (the 2k & NT 4.0)?

I can't speak for him but for 100% compatibility two criteria must be met - Function Names and their Ordinals.

The latter case - out of order functions, is a biggy. In the past it was common for applications and even Windows to call functions in a DLL by importing them via ordinal. So if someone recompiled a DLL without changing a single line of code but re-sorting them out of original order an incompatibility is created because the 3rd ( or whatever ) function is completely different in another version of the same DLL. Having never used it myself ( so I don't know for sure ) I would expect that this topic is an important part of the KernelEx project here at MSFN.

Naturally in the former case the function "Names" implies that everything else is the same within the function ( i.e., if it has same exact name then it's still ANSI/Unicode, same arguments, etc, as its same-named predecessor ), but even this might not always be the case since there is nothing stopping some programmer from changing ( for example ) from ANSI to Unicode but leaving the NAME unchanged. Likewise a function could be completely rewritten and butchered to use a completely different prototype while keeping the NAME unchanged. These are exceedingly bad ideas but cannot be ruled out. But for the sake of argument its *assumed* that same name means same function.

How was this failure vector even possible? It was considered faster and more efficient to call by ordinal, in other words cutting corners. But speed and efficiency isn't everything. IMHO consistency, stability and compatibility are. But that ship has clearly sailed!

[jaclaz]

If I may, the issue you just pointed out (ordinal vs. name) is only one of the causes of the so called "DLL hell", but it cannot be underestimated how a large part of it is to be attributed to sloth and "unneeded complexity" (and in some cases plain stupidity) on behalf of the actual programmers.

Some reference:

http://www.codeproject.com/Articles/4896/The-DLL-Hell-Problems-and-Solutions

Please note how this has been removed:

http://msdn.microsoft.com/en-us/library/ms811694.aspx

but we can have it through the WayBack Machine:

https://web.archive.org/web/20100305054645/http://msdn.microsoft.com/en-us/library/ms811694.aspx

Part of it is due to "abuse of DLL's" however.

What I mean is, if you have to make 2+2 you normally have a mental table for it and you know that it makes up 4.

You do not search for an algorithm capable of doing addition on integers, real, fractional, and imaginary numbers with precision up to 2^31 and 25 decimal places.

What a number of programmers abuse is the use of such external, often overcomplicated (because they are meant for some non-trivial scope) code when there is in the programming language already the provisions to make a smaller, simpler, more suitable and faster algorithm.

The use of some "programming studios" is another culprit, when examining a program for dependencies (let's say with Dependency Walker) you will find how there are often completely unneeded dependencies to functions that also exist in another .dll which is actually needed or dependencies created "automagically" by the CASE tool that have no real meaning/use.

What is IMHO absurd is that the good MS guys (who have had "full control" on them since the very beginning) in all these years did not manage to keep at least the so-called "known" DLL's and the small bunch of VCC redistributables under control and their way out (supposed "solution" in their perverted minds) is the total folly that Windows Side-by-Side (WinSxS) "assemblies" represents (including their crazy folder/file names).

jaclaz