I'm trying to register a dll file(32bit) in windows 8.1 os,
but somehow I check the dll from Dependency Walker and find out
Some .dll files are missing in WIN8.1 OS as follow:
1. API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL
2. API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
3. API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
4. API-MS-WIN-CORE-SHUTDOWN-L1-1-1.DLL
5. EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
6. IESHIMS.DLL
I google it and the problem is about upgrade OS to WIN8.1,
but how can I make these .dll files back?
or is there any way to solve this problem?
Related
I'm getting a DLLNotFoundException in standalone builds on some windows machines, others work perfectly. Dll file is definitely in the plugins folder, copied it to the projectName_Data folder too but no difference.
Also attempted to add dll to streaming assets folder and set new path (Environment.SetEnvironmentVariable) as above but that didn't work either.
Using Unity 4.5.5 btw
Any help at all would be greatly appreciated!!!
What I found is that the error DllNotFoundException is, in some circumstances, very misleading. Unity is not to blame for this because when something goes wrong with dll loading, Unity simply doesn't have that dll in memory and tells you so.
As Keysosaurus says, Visual C++ Redistributable must be installed for your standalone version to work and in most cases this solves the trouble but there can be other reasons like third party dependencies.
In case you are using third party libraries then you must also copy all the needed DLLs or SOs to your executable's folder.
For example I am working with OpenNI 2 and when I build I immediately copy all files from C:\Program Files (x86)\OpenNI2\Redist folder to the folder that contains the .exe. Not doing this results in DllNotFoundException.
Also don't forget that DLLs (and SOs) must match the architecture you are targeting so if you are targeting x64 (64 bit) then your DLL must be x64 too and if you try to use a x86 (32 bit) DLL Unity will be confused and will not load that giving you the same error.
As a side note bear in mind that Unity 5 comes both in 32 and 64 bit versions. In order to run your game in Unity Editor, all third party libraries must be present in both x86 and x64 (in Unity's conventional folders) or at least the one that matches you Unity Editor's architecture.
I discovered that the problem was that players needed Visual C++ redistributable installed, which can be downloaded here:
https://www.microsoft.com/en-gb/download/details.aspx?id=40784
I am developping a multi-platform application under Linux. To build the Windows versions, I make use of cross-compiling with MinGW. For "first" tests, I am using wine. First, I have started with MinGW32 and wine configured for Windows XP.
I need to build tier dll and my own dll. Build is alright. If I copy them in C:\windows\system32\ and run my application which use these dll under wine, it does not find them. If I put a copy of the dll in the same directory than the application, it works.
I have tried :
~/.wine/drive_c/windows/system32/
/root/.wine/drive_c/windows/system32/
If I run the explorer (wine explorer), and browse into C:\windows\system32\ , my dll are not there !
Thus, how can I make wine find home made dlls ? I have had a look at winecfg and winetricks, but they are of no help.
Cheers,
Laurent.
Try creating an installer for your application, using nsis or something, and creating a package that includes your dll and application. Then install that installer using wine.
I installed the Windows 8 SDK (which is supposed to include the DirectX SDK).
But my directX stuff is not working (See this question about that).
But on a seperate question, I wanted to ask where all the DirectX SDK stuff is supposed to be after you install the Windows 8 SDK.
If the answer is "lots of places" then lets go with this one file: d3dcompiler_43.dll
I found the answer here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275.aspx
It says:
Any project that uses run-time shader compilation must have D3DCOMPILER_46.DLL copied to the local executable path for the project. This DLL is available in this sub-directory of the Windows SDK installation under %ProgramFiles(x86)%\Windows Kits\8.0\Redist\D3D\ where is x86 and x64.
I have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
I'm developing a C#/WPF app that talks to a USB device using some custom 32 bit dlls. It's developed as an x86 app, and installed with WIX. When I install the package on a 64-bit machine, the program files get installed to Program Files (x86) as I expect.
The dlls are installed to the SystemFolder using WIX. On 32-bit machines, this means C:\Windows\System32. On 64-bit, they end up in C:\Windows\SysWOW64. This is ok, but when I run my app, it is unable to find the dlls (it uses them via [DllImport...]).
So, what is the right way to make my app find the dlls, whether they are in System32 or SysWOW64?
Thanks
Tom
If it is a default C# app, it will automatically be a 64 bit app on 64 bit Windows (C3 defaults to 32 bit on 32 bit Windows). Go into the project properties in your development app and explicitly set the architecture (I think; I don't have Studio up right now) to 32 bit. If it is running as a 64 bit app, it won't be able to use your 32 bit DLLs.
Please check if the dll in application is of the same version as that in the sys32 or wow64 folder depending on your version of windows.
You can check that from the filesize of the dlls.
Eg: I faced this issue because my libeay.dll file in system32 had a different dll than my libeay.dll file in openssl application. I copied the one in sys32 into openssl and everything worked well.