I put the 64-bit DLL file in the System32 folder, and the 64-bit DLL file in the System32 folder was changed to a 32-bit DLL file. I do not know what just happened to the DLL file that I put. What was it that happened? This issue should be fixed.
Exactly what did you do and what leads you to believe that the 64 bit DLL changed to 32 bit. What you describe is impossible. Windows is a complex OS and it is easy to misunderstand what you see. Things are often not as they seem.
Using the EXE 64-bit Detector, these are the details. I did not edit any DLL file, and I have never edited any DLL file.
Code:File Path: C:\Windows\System32\xvidvfw.dll File Type: 32-bit ASLR Status: Enabled DEP Status: Enabled SEH Status: Enabled |*| This is 32-bit Executable File |*|
The DLL has not changed. A DLL cannot be changed by editing a few bytes. That would take essentially a rewrite.
The issue is with the exe64bitdetector which is itself a 32 bit program. This has implications in this situation.
In a 64 bit OS the "system32" folder is used for 64 bit system files while the "syswow64" folder is used for 32 bit files. There are good reasons for this which I won't go into here. When a 32 bit program tries to access "system32" it will be silently redirected to "syswow64" which contains the files it needs. This allows older 32 bit programs that predate 64 bit systems to work as expected with a 64 bit OS. You must have a 32 bit "xvidvfw.dll" file in "syswow64" or you would get an error.
exe64bitdetector.exe, being a 32 bit program, will actually see files in syswow64 instead. Use the program to check any DLL in system32 and you will see they all are reported as 32 bit. A 32 bit program can be designed to get around this redirection but even the latest version of exe64bitdetector.exe does not do this.
Instead of specifying "system32" in the comand line you can substitute "sysnative" instead. This will alow you to actually access the system32 folder. This only works for 32 bit programs running on a 64 bit OS. Don't look for a "sysnative" folder as it does not exist.
When a 32 bit program tries to access the "Program Files" folder it will be redirected to "Program Files (x86)" for similar reasons.
As I said, things are not always as they seem.
Okay. The EXE 64-bit Detector software was wrong at that point. Here is my quick update.
Using the NotePad program, here is what I can see.
For C:\Windows\SysWOW64\xvidvfw.dll, it contains PE L. That is 32-bit.
For C:\Windows\SysWOW64\lagarith.dll, it contains PE L. That is 32-bit.
For C:\Windows\SysWOW64\ff_vfw.dll, it contains PE L. That is 32-bit.
For C:\Windows\SysWOW64\huffyuv.dll, it contains PE L. That is 32-bit.
For C:\Windows\System32\huffyuv.dll, it contains PE d. That is 64-bit.
For C:\Windows\System32\xvidvfw.dll, it contains PE d. That is 64-bit.
For C:\Windows\System32\lagarith.dll, it contains PE d. That is 64-bit.
Okay. So, those DLL files are in the correct file paths. But, the issue that I am having is that HuffYUV is not in the video compressor list of HyperCam 2 (64-bit).
On my computer, HuffYUV is in the "ffdshow video encoder" configuration.
- - - Updated - - -
Okay. HuffYUV is listed in Video Compressor from HyperCam 2, and it happens by "Limit screen capture to max. 24 bits per pixel (may be slower)".
Quote
