I'm using this code in XP 32-bit OS to get the %windir%\windows\system32 folder path.
sysFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.System)
What I want to know is that will this same code return the %windir%\windows\syswow64 folder when used in Windows 7 (64/32-bit)?
It will return c:\windows\system32, even in a 32-bit program that runs on the 64-bit version of Windows. Do not fix this, it doesn't need fixing. Because when you use that path, Windows will automatically remap it to c:\windows\syswow64. The file system redirector takes care of it.
I tried on my Windows7 box with .NET 4.0
This code:
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.System));
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.SystemX86));
Prints the following from both 32- and 64-bit process:
C:\Windows\system32
C:\Windows\SysWOW64
Nope. On my Windows 7 64-bit box, targeting x64:
C:\Windows\system32
Related
Environment.SpecialFolder.ProgramFiles and Environment.SpecialFolder.ProgramFilesX86 returning x86
my pc is 64 bit
so how to get Program Files on Windows 64 in vb.net or #c
Dim ProgramFiles As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)
Dim ProgramFilesX86 As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
ProgramFilesX86 will always return the Program Files (x86) folder path while ProgramFiles will return the same path if your app is running in a 32-bit process and the Program Files folder path if your app is running in a 64-bit process.
If you target the x86 platform then your app will always run in a 32-bit process, meaning that it won't run on an OS that doesn't support 32-bit processes.
If you target the x64 platform then your app will always run in a 64-bit process, meaning that it won't run on an OS that doesn't support 64-bit processes.
If you target the AnyCPU platform and check the Prefer 32-bit box then your app will run in a 32-bit process if it can, otherwise it will run in a 64-bit process.
If you target the AnyCPU platform and uncheck the Prefer 32-bit box then your app will run in a 64-bit process if it can, otherwise it will run in a 32-bit process.
Your app would have been running in a 32-bit process because you checked the Prefer 32-bit box - note that it is checked by default - so your app could only see the Program Files (x86) folder, regardless of the OS. It doesn't make sense for 32-bit apps to do anything related to 64-bit processes.
I have downloaded the CefSharp 71.0.0-pre01 Source code from the official release, and built it successfully by VS 2015 on my Windows 7 Ultimate x64.
I have checked all x86 and x64 release build, and the project built all 22 items successfully includes the example exe.
The WinForm Example folder has 2 output in the bin, the x64 release can run well on my Win7 x64, but the x86 (32 bit) release doesn't work. Once I run the "CefSharp.WinForms.Example.exe", it shows
CefSharp.BrowserSubprocess has stopped working
When I click to check issue details, it shows:
Event Name: APPCRASH
Application Name: CefSharp.BrowserSubprocess.exe
But when I run the x86 release on the Win7 32bit machine, it works well.
I wanted to build an AnyCPU version but the project doesn't support AnyCPU, then I assumed the x86/32bit should work on both 64/32 machines. Is it possible to do that?
A case I've experienced is setting max_old_space_size to a large value which causes render subprocess to crash on startup when running in 32bit mode. Removing this option resolved the issue for me.
I have windows embedded 8.1 Industry Pro (64bit) and office 2010. I did everything that I was supposed to do ;
Just extract the .ocx file from the .cab file and Copy to the system folder c:\windows\sysWOW64 for 64 bit systems
Use regsvr32 through the command prompt admin to register the file "regsvr32 c:\windows\sysWOW64\mscomct2.ocx"
But when I go to additional controls, there's no "microsoft date and time picker."
What can I do ?
Thanks
After 2 hardworking days finally I found my problem. My problem was office64 bit edition not supports every activex like mscomct2.ocx when I installed office32 bit problem solved.
I have installed VB6 on my Windows 8 64bit laptop, I installed SP6 and when I try to run projects that I had working on my windows 7 32bit laptop I am running into a problem with common functions like Space$ or Str, where it tells me "Can't find project or library".
After some googling I have tried copying over my comdlg32.dll from the windows 7 laptop over to the syswow64 folder on the win8 laptop but saw no change. I have installed SP4 after I read that would solve it but that didn't work either. I also read that msderun.dll would help but after dropping that in syswow64 I did not see any change either.
Does anyone know how to fix this on Windows 8?
Find msvbrun60.dll (in 32 bit windows type regsvr32 msvbvm60.dll, for 64 bit do the same with c:\windows\syswow64\regsvr32 msvbrun60.dll). All those functions are in vba library which is msvbvm60.dll. If that fails reinstall the runtime files http://support.microsoft.com/kb/290887.
I created a dll file built (Project:win32 app, ATL and COM object using Visual studio 2008) in 32 bit. In win 7 32 bit OS, After registering my dll i'm getting "ABC" option in context menu(on right click). Now i move to win 7 64 bit OS. Dll loaded successfully, but i'm not getting "ABC" option on right click(in context menu). Can anyone please point me where i went wrong or any suggestions ?
Note: Right click on Folder gives "ABC" option.
A shell extension compiled for 32bit will run only in a 32bit process. The Windows Explorer of a 64bit Windows is a 64bit process, so it requires a 64bit shell extension.
If a 32bit application would use the fileopen dialog (on a 64bit Windows), the dialog would require a 32bit shell extension. So it's recommended that you install your extension like that:
Win32: 32bit Shell Extension
Win64: 64bit and 32bit Shell Extension
To do this, you have to give different GUIDS to the 32bit / 64bit shell extension. Hope that makes it a bit more clear.
Edit: As Raymond suggested, it seems that you can use the same GUID for both extensions.