The Problem:
Environment: Using Visual Studio in Windows, most any version since the 2000's.
Pain point: I have a DLL class library in 32-bit-preferred project and I can't see or write to the necessary files in System32.
The Solution:
Explanation: System32 is a virtualized folder on a 64-bit machine. 32-bit applications are redirected to a different folder specifically geared towards the needs of 32-bit applications. I believe this folder is named WOW64. You need to stop the redirection in certain instances.
The Fix: Use Sysnative instead of System32!
Example: Trying to access c:\Windows\System32. Should use c:\Windows\Sysnative as your path instead!
Note: You will never be able to visit Sysnative in Windows Explorer. It simply tells Windows not to redirect to another folder. Buyer beware :)
If you need Admin rights, use an app. Manifest with admin or higher rights specified.
Related
I use a machine where I don't have administrator rights. I've been able to run programs without admin rights by extracting the program's .zip file to a directory I have created on my desktop. However, I can't find such a .zip file for Visual Studio.
Is there a way to install Visual Studio Community Edition without administrator rights?
Practically no. Visual Studio (Express and above, excluding VS Code) consists of multiple components that must be installed as admin, and will be required for the app you're debugging to be available as system-wide component. It might be possible to use ThinApp or its equivalent, but ThinApp can't even work with VS 2010 and it was by far the best of its class.
A (resource intensive) alternative to get VS on any PC will be packaging a VM with VS installed, either creating one yourself or get a ready-made ones. VirtuaBox is available as portable fork if you can't even get Hyper-V tools installed. But this still require kernel drivers installation, which means at least one-time admin access. Depending on your internet connection & budget, it might be more practical to setup a VPS with VS installed, then remote there.
Basically, youre going to need to download an iso of windows, then download QEMU, and run it as invoker by doing that batch file thing (https://techcult.com/how-to-install-software-without-admin-rights/). Set it to anywhere, and then figure out how to boot it to QEMU cause I have absolutely no idea how (ive only done it with Kali Linux). and just install VC on there. Sorry about being so vague.
There is no way to install or use Visual Studio on Windows without admin rights. You can either use a different program to write your code in and then compile using a different compiler. Or use qemu (since it does not require admin rights) to run a windows virtual machine.
I have a very strange problem.
I am trying to run a console application that I build using VS2010 and get the error mfc100d.dll not found. However this dll is present in c:\windows\system32 and my path is c:\windows\system32
If I copy the file from c:\windows\system32 to my current directory it works.
If I add C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC100.DebugMFC\ to my path, it also works.
It was all working fine until I uninstalled a program yesterday and installed new version of it. But the thing I just can't understand is why I am getting errors when the mfc100d.dll is really there in the C:\windows\system32 path.
And, yes, I do have the rights to read the file, how else can I copy it...
In a 32-bit application running on 64-bit Windows, accessing the System32 directory gets redirected to the SysWOW64 directory. Take this output from 32-bit Python, for example:
>>> import os
>>> print(os.path._getfinalpathname(r'C:\Windows\System32\mfc100d.dll'))
\\?\C:\Windows\SysWOW64\mfc100d.dll
Keep in mind that both filesystem and registry paths can get redirected due to WOW64 and UAC, so you don't always get exactly what you asked for! This can catch you off guard if for some reason you end up running a 32-bit command prompt via SysWOW64\cmd.exe, especially if you end up running a mixture of 32-bit and 64-bit applications in the same console window.
If you uninstalled something maybe your environment variable was reset. Did you check on that?
Try to check your PATH, see if there are several mfc100d.dll exist in the search path and one of them get broken. (possibly due to the uninstallation)
Check where that console application is trying to fetch that mfc100d.dll file using Dependency Walker . Then place mfc100d.dll to the path where it is trying to fetch it.
I created an installer using InstallSheild Limited. During the install process, I have a Custom Action which runs a C++ exe after registering the product. In the C++ exe, I move files that are in the installers program directory to various places on the computer.
Now, I need to make the uninstaller be able to remove those files. Is there a way to do this in InstallSheild Limited Edition. If not, what can I do to achieve the same results?
I have a software written in C++ installed in some 1000 PC which is having some difficulties with windows UAC. I'm trying to make things work properly but I would need some help to understand the problem and find correct solution.
Situation is as follows: I need to write some data in some text / xml files, so I started (in XP) to write them in the executable folder. Not recommended, I know. When Vista kicked in, all files started being saved to the VirtualStore folder, which was fine for me, so I left things untouched. I had some issues back then with a couple of users (see problem 1) but I fixed them by hand and that was it. Now with Windows 8 I'm facing different problems (problem 2) and I want to fix them properly once and for all.
First problem: with Windows Vista it happened that some users eventually found their software "empty", as it was when just installed. All their work on it was gone. It turned out that suddendly Vista was looking for their files in C:\Program Files\{MyApp} instead of looking in the VirtualStore. Copying the files from VirtualStore to Program folders solved the problem, never understood why
Second problem: now with Windows 8 some users [a minority of them] experience a different, strange fact; my app does not seem to be able to create files in the VirtualStore, but it can edit existing files. So if I create the files manually, everything works. If not the app does not work: files are not modified neither in the program folder nor in the virtual store
Now I want to fix up things. My plan is to move all the files that need modifications in CSIDL_LOCAL_APPDATA and to have the software save stuff there. Only executables will be in the program folder. For backward compatibility, though, it seems I cannot use SHGetKnownFolderPath which seem to be Vista+ specific. So I would use SHGetFolderPath, which is deprecated, I know, but should work in XP and act as a wrapper of SHGetKnownFolderPath in Vista+, which is good for me.
My questions:
any ideas about my problems 1 & 2? I'd like to understand them in order to be sure I defeated them complitely.
is my plan UAC compliant? As far as I understand it is, but...
any way to assure XP compatibility but for my workaround? I do not feel comfortable using deprecated functions, but I definitely do not want to have two versions (XP and Vista+) to deal with!
Thank you very much for any help you can provide.
Luca
These are my ideas to problems 1 & 2:
1. If you are writing the files your application is working with, your files will be written in a sub-directory of C:\Program Files. In order to write files at this location (C:\Program Files), your application must be run as Administrator. For compatibility reasons Windows Vista will write data to VirtualStore, if you try to write data to directories where you need Administrator rights to write data to.
2. Windows 8 does not use VirtualStore anymore. Read access does not require Administrator rights, however.
Yes, your plan is UAC compliant. Your program and the files your program uses must be saved in two different directories.
I would use the ShGetFolderPath function in order to get the path of the AppData directory. Additionally this function is compatible with Windows XP. You might check the operating system version and use the appropriate function/interface for this version. GetVersion and GetVersionEx have been changed in Windows 8. This is why I recommend the use of the Version Helper functions for version checking purposes on Windows 8.
I had to create an executable (using Borland C++ Builder 6) in place of a batch file for Windows 7, since permissions didn't allow ordinary users (non-admins) to run the necessary batch. We've got a number of different Windows 7 machines, some 64 bit and some 32, etc. The problem I'm running into is that the "Program Files" directory is hard coded in to the program, but it's not always the RIGHT program files directory, which leads to some errors on some machines.
I'm familiar the method for getting the program files dir from the registry, but I'm afraid this won't work on all machines because of permissions settings not allowing programs to access the registry. I've been searching high and low for a function like GetWindowsDirectory, but to no avail. Does ANYONE have any suggestions?
EDIT:
I've programmed this on a Windows XP Machine to simply be placed on Win7 (No way to change or avoid the XP/7 thing, crappy as that may be). It's a simple utility that needs no installation; it's just placed in a file. It just needs to go out and find the program files directory to perform some tasks.
This is first of all a deployment problem. You will have to copy/install your program to c:\program files (x86) on a 64-bit machine. You can simply use c:\program files in your code, Windows redirects it to the (x86) directory.
There is otherwise no easy cure for trying to bypass UAC. You'll have to embed a manifest in the executable to ask for admin privileges. The user gets the UAC prompt to let her know that you are going to be hacking the private parts. How to do this with such an old tool isn't obvious to me, you'll probably have to embed it in the .rc file. Or use a .manifest file.
How to get Program Files folder path (not Program Files (x86)) from 32bit WOW process?
Use SHGetFolderPath with CSIDL_PROGRAM_FILES.
There's a newer version called SHGetKnownFolderPath if you're always on Windows Vista or later, but you might need to update your Platform SDK. If you're still using Borland C++ 6, I suspect your Platform SDK might be older. In that case, you should be able to use SHGetFolderPath.
after installing the software, go to :
C:\Program Files\Borland\CBuilder6\Bin
Right click on bcb.exe file, choose
Properties -> Compatibility
Select the option - Run this program mode Windows XP(Service Pack 3) and Privilege Level
then, select the option Run as administrator, and then click Apply.
This works for my problem.
On windows 7 x64, just create a junction point in "c:\Program Files" pointing to the actual folder where the installation is in "c:\Program Files(x86)". This should be done by the same user who installs the software. That should not only take care of your problem but also third party packages that would not otherwise work on Win 7 x64.
If you don't know what a junction point is, just read the help for mklink.