Jump to content

Welcome to MSFN Forum
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 Account Create an Account



Photo

Modifying/Replacing Shell32.DLL on NT 4.0

- - - - -

  • Please log in to reply
43 replies to this topic

#1
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag
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.


How to remove advertisement from MSFN

#2
Tripredacus

Tripredacus

    K-Mart-ian Legend

  • Super Moderator
  • 9,794 posts
  • Joined 28-April 06
  • OS:Windows 7 x86
  • Country: Country Flag

Donator

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.


MSFN RULES | GimageX HTA for PE 3-5 | lol probloms
tpxmsfn1_zps393339c1.jpg

#3
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag
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.

#4
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,467 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

To keep this Topic "connected" -

http://www.msfn.org/...lidated-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/...r-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. :yes:

 

(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.videol...hp?f=14&t=47897

 

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

https://wiki.videola...:Usage:Version/

Still looking for HOW it worked...

Followup - here you are again...

https://forum.videol...p?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/...t/docs/2863.htm

(err, um NO! this is for SPECIALfolderpath)


Edited by submix8c, 22 January 2014 - 11:02 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#5
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,197 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

http://www.msfn.org/...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. :unsure:

 

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



#6
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,467 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

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.microsof...1(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. :unsure:

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

http://msdn.microsof...y/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 by submix8c, 22 January 2014 - 04:19 PM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#7
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
Attached File  Shell32vlc.7z   444bytes   7 downloads

Shell32vlc.dll is a wrapper that forwards three calls as needed (by VLC 1.1.10):
LIBRARY   Shell32vlc
EXPORTS
 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 by jumper, 25 January 2014 - 10:16 PM.

Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#8
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag

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.



#9
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
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 by jumper, 25 January 2014 - 10:23 PM.

Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#10
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag
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 by ironman14, 26 January 2014 - 10:02 PM.


#11
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
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 by jumper, 27 January 2014 - 04:39 AM.

Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#12
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
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!
Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#13
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag
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)?

#14
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,048 posts
  • Joined 24-September 07
  • OS:none specified
  • Country: Country Flag

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!

... Let him who hath understanding reckon the Number Of The Beast ...


#15
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,197 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.codeproje...s-and-Solutions

 

Please note how this has been removed:

http://msdn.microsof...y/ms811694.aspx

but we can have it through the WayBack Machine:

https://web.archive....y/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 :w00t: 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



#16
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,467 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

Thx, jaclaz for the links. Interesting (to say the least) reading. What surprises me (and this is where I agree with you wholeheartedly) tha MS, having had the contract with the good folks at IBM to develop DOS didn't have the sense to have learned some things from the IBM Mainframe Operating Systems and Applications. Strangely, Apple (the MS offshoot) used the same IBM-nonsensicle method of rolling out / tracking Fixes.

Can you say backwards compatible reentrant modules?

It appears that MS' point of view was "work around our problem this way and BTW get more hardware". :crazy:

(Apologies for also chiming in O/T but that article knocked me on the floor.)

Side notes -

I believe you meant SHELL32.DLL->SHELL32.NT4 (since this is an NT4 problem).
And thx for the "wrapper" (I call it an "intercept" / "interface"). -Not yet tested!-


Edited by submix8c, 28 January 2014 - 12:13 PM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#17
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag

After seeing different responses, I was determined to find out what exactly caused the problem. Using dependency Walker, I found out that Shell32.dll was attached to libvlccore.dll. So, I opened up libvlccore.dll in HxD, and found Shell32.dll. I renamed this to shell32.VLC and the hexes changed automatically. I saved the file and launched VLC. I was greeted with a new error message:

 

"The application or DLL C:\Program Files\VideoLAN\vlc\libvlccore.dll is not a valid Windows NT image. Please check this against yor installation diskette."

 

And when I opened Dependency walker to check, it says Shell32.VLC, but shows the error icon next to the file name. Also, it still says that SHGetFolderPathW is not found. I probably did something wrong with the hex editor. Maybe I edited the wrong file? I did figure out also that libvlccore.dll was attached to libvlc.dll, but I am not sure what that means.



#18
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
> ...I saved the file and launched VLC.
So far, so good.

> And when I opened Dependency walker to check, it says Shell32.VLC, but shows the error icon next to the file name.
1) Confirm that you have SHFolder.dll in your system directory.
2) Make sure that you renamed Shell32vlc.dll to Shell32.VLC and put it in your app folder.
3) In the DW Options menu, Configure the Module Search Order so that "The application directory" is moved up to the top of the search order.

We may have a problem with API forwarding on NT (and also 9x).
What version of VLC are you working with? I need to study the exact files you are working with.

Edited by jumper, 01 February 2014 - 03:14 AM.

Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#19
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag

I made sure I had done the following 3 steps. The icon still appears.

 

One note though. I know under NT 4.0, SHGetFolderPathW exists in Shfolder.dll (installed with IE6). However, VLC calls for it specifically in shell32.dll. I was thinking that if I used the hex editor again on libvlccore.dll, and instead of shell32.vlc, I could type shfolder.dll and that may work.

 

Here are the files I am working with:

Shell32.vlc

vlc.exe 

libvlccore.dll

 

I am using VLC 0.9.8a.



#20
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
> instead of shell32.vlc, I could type shfolder.dll and that may work.
Good idea. :yes: But "shfolder.dll" is one character too long so make a local copy and name it shfolder.00 or shfoldr.dll

BTW, I think this version of VLC requires SSE. FineSSE might work if you only have a PII. (FineSSE should work on NT, but hasn't been tested yet.)
Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#21
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag

@ Jumper:

In a past post, I had heard you suggest modifying the KnownDLL of SHELL32, which is a very good suggestion. The only problem is that most applications require the specific DLL they call for. I also thought that if I replaced ALL the KnownDlls of NT 4.0 with the 2000 versions, the 2000 versions would connect and be stable (reboot correctly). However, I am not allowed to modify KnownDLLS by default, as the system is constantly using them. I was considering the following:

- Rename the 2K Shell32 to Shell2k.dll

- Add it to the system folder.

- Rename the NT 4.0 Shell32 to Shell32.old

- Rename Shell2k.dll to Shell32.dll.

I would need NT permissions for this. In the User Manager, I gave myself access to take ownership of files and other directories, but that doesn't seem to be enough. How do I use NT permissions in NT 4.0?



#22
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
The sequence should be:
- have disaster recovery plan ready
- Rename the 2K Shell32 to Shell2k.dll
- Add it to the system folder.
- Edit KnownDLLs in registry to redirect: Shell32 -> Shell2k.dll (need to be admin to edit registry?)
- reboot
- If system reboots okay, Shell32.dll will no longer be in use and can be renamed

>How do I use NT permissions in NT 4.0?
I really don't know. I think you need to be logged in as an administrator.
Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#23
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag

 

This is shell2k.dll in the system32 folder.

 

 

As you can see, this file was originally named shell32.dll.

 

I may post a couple times, but because I have multiple pictures.



#24
ironman14

ironman14

    Member

  • Member
  • PipPip
  • 209 posts
  • Joined 16-October 13
  • OS:Windows 2000 Professional
  • Country: Country Flag

 

This image shows the shell2k.dll value in the KnownDlls section of the registry.

 

 


Edited by ironman14, 20 February 2014 - 08:11 PM.


#25
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
Looks good. If you've rebooted, then the original Shell32.dll should be unlocked. You can now replace it and restore the original KnownDlls setting, or leave things as they are. I suggest leaving things as they are.
Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users