I am trying to edit the corflags file so that I can run 32bit applications on a 64 bit pc but everytime I try to edit the file using something like corflags.exe assembly /32bit+ it comes up with the error message cf001 could not open file for writing.
Now I have tried a lot of different options such as:
Running in administrator mode;
Finding the file using a search and checking read only is not ticked
Checking that user full control is ticked
Tried to set the whole folder to non read only
When trying the whole folder, it goes through looking like it has set read-only, but then I click OK and re-right click on the whole folder, the box is filled in (not ticked) does this mean that part of the folder is read only and why does it reset to read only?
I just faced the same problem and have tried the same things.
Run cornflags from an elevated ("Run as administrator") Visual Studio Command Prompt. I did the same for a copy of the original .exe just to make sure no other process was using the program.
Create a copy of the file you intend to target with CorFlags.
(e.g. "WcfServiceHost.exe" --creates--> "WcfServiceHost - Copy.exe")
Rename the original file to something else:
(e.g. "WcfServiceHost.exe" --> "WcfServiceHose_Original.exe")
Rename to copy to the original file name
(e.g. "WcfServiceHose - Copy.exe" --> "WcfServiceHost.exe"
For my purposes, I created copies and named them describing their configuration:
Example:
WCFServiceHost_With32BitOn.exe
WCFServiceHost_With32BitOff.exe
Now I can destroy the WCFServiceHost.exe files and create them from these pre-modified copies. No more CorFlags operations necessary.
Note: this is basically a more verbose version of #RMalke answer and that answer should be marked as the answer.
I realise this is years later, but for anyone else looking, I found that the quickest way was to copy cmd and corflags.exe into the same folder as the one you want to edit. Then run cmd as admin from there.
Related
I have a Visual C++ for Linux project in VS2017 that I'm building on a Raspberry Pi running Raspbian. This project consists of a single source file (main.c) and an image (test.jpg). When building the project, I want the image file to also be deployed to the pi, so that the code in main.c can do something with it locally. However, I can't figure out how to do this
The image file's Content property is set to True, as is Included in Project. In the project properties, under Copy Sources, Sources to Copy is set to "#(SourcesToCopyRemotely)" and Copy Sources is set to "Yes". However, when I build, only main.c is copied to the Pi, and the compiler output is just a single .out file. I hoped to also see test.jpg there, but alas.
This article mentions that #(SourcesToCopyRemotely) defaults to all files in the project. However, when I evaluate the value of #(SourcesToCopyRemotely, it evaluates to just "main.c".
How do I make sure content files in my projects also end up in the build directory, along with the .out file? Preferably without having to manually enter each filename in a post-build step.
It turns out this is a bug in VC++ for Linux. A workaround, currently, is to use Additional Sources to copy. There's a caveat though: it doesn't work with remote paths that start with ~. So you can't use $(RemoteRootDir) if the Remote Build Root Directory setting is set to the default of "~/projects".
I've currently got Remote Build Root Directory set to "/home/pi/projects" and for each file I want to copy to the build directory I set Additional Sources to Copy to "[filename]:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$Configuration)/[filename]". For instance:
firstimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/firstimage.png;secondimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/secondimage.png
Right-clicking on the non-source code file to open it's properties page and flagging as Content in the General tab will cause the file to be copied to the remote. There is no need to add anything to the Copy Sources tab. The Copy Sources page of the project properties must show the default of #(SourcesToCopyRemotely). And when you edit this setting the macro should show an expansion with the additional files included.
I have found that it necessary to refresh the macro by clearing Source to Copy and then restoring it to the default after you have marked the additional files as content.
I have encountered problems when the additional files are not in the same folder as the C++ source files on the Windows host and/or you want to put them somewhere else on the remote. There are several open issues on the VCLinux GitHub site like this one so it will be worth reporting any problems you have on there.
[VCLinux 1.0.6 on VS Pro 2017 + Debian Jessie remote]
The "Pre-Build Event" section of the project properties offers "Additional Files To Copy". Addressing my file there (relative to the solution) showed following in the output when building:
Copying file 'C:\myfilepath\resource.png' to '/home/pi/projects/myproject/resource.png'
It is possible to move the files to the final destination then with Remote Post-Build Events (mv source destination). Not the most elegant way, but the first thing I got working..
I have an old VB6 app that I'm distributing with the PDW. I need to determine after installation if it's the first run of the app. What's the simplest way to do this?
Currently, I install a dummy text file and use its existence as evidence of first run. If firstrun.txt is in the app directory, I open a subroutine that creates some directories and copies some files and then deletes the txt file. The next time, it skips the subroutine because firstrun.txt isn't there. Works perfect until users get an error code 70 because they don't have the appropriate permission to delete the file.
This is the code I'm using to delete the text file:
mobjFSO.DeleteFile App.Path & "\firstrun.txt
Anyone have a better way? Or could someone tell me how to allow the program to delete the file regardless of permisson?
Thanks in advance!
Try the opposite approach. If no file exists, assume it is the first run. After the first run does its thing, write a file -- but write it to a user area, such as C:\Users\myuser\AppData on Windows. This would be a more appropriate place to store this kind of data and you won't suffer the same permissions issues.
I am trying to open a downloaded .exe file but it closes as soon as it opens. Is there any possible way so that I can open it for a longer duration to read the content.
It's probably a console application rather than a GUI application. Use the command prompt to run the .exe.
Do the following...
Hold down your Windows key on your keyboard and then tap "R".
This will bring up the Run dialog. Type in "cmd" (without the quotes). Hit enter.
(this will work in all Windows versions - browsing the start menu/screen differs in each version)
If you saved the file to c:\downloads and it's called myFile.exe, type
C:
cd C:\Downloads
myFile.exe
Some of the steps are a bit redundant - if you know what you're doing in the command prompt then skip as needed (but then you probably wouldn't be posting this question). This will work even if you saved the file to D:\downloads.
Another example - if you saved the file to D:\folderA\Folder with a space\ and the file is called "my file with a space.exe" then type
D:
cd "D:\folderA\Folder with a space"
"my file with a space.exe"
If there is an issue (eg it's a 64-bit executable and you're on 32-bit Windows) then you may get a better error message at the command line.
There are so many reasons why the executable does not run. Here are some ways to check what is going wrong:
Is it your .exe? Do you known the "normal" behavior?
When you download it manually, it the result the same?
Do you download the .exe manually or via your application?
Do you see any problem in your Windows Event Viewer?
Is it the same result if you try to download the .exe via different browsers (IE, FF, ...)?
More details are welcome!
The nuget.exe file is not a console GUI application but rather a console package. Once you've downloaded it, you'll want to place it in a folder outside your Downloads folder. For example, C:\NuGet\nuget.exe - then set it as a PATH variable so that it's executable from anywhere.
I just installed WinGHCi. When I try to load an .hs file with Ctrl+L, it opens the file browser in C:\Program Files (x86)\Haskell Platform\2012.2.0.0\winghci which is where I installed this. I don't want it to go there by default, I keep my code files in a different directory on a different drive and I don't want to have to navigate to D:\MyPath\Haskell every time I load a file.
I tried to set the "Start in" field of the shortcut I use to launch WinGHCi but it changed nothing.
How can I make WinGHCi look in my own directory by default?
It opens in the last directory you opened a .hs or .lhs from.
Try opening something from the folder you want, exit, restart.
Did it restart where you were?
Try working like that for a while, and if you like it (I do) then you're fine.
If you really do want to go to the same place every time, perhaps there's a way.
I can't find any setting to control this, but the information is stored in the registy.
Mine is at
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Haskell\WinGHCi 1.0.6]
"WorkingDir"="D:\\Files\\Andrew\\prog\\haskell"
You can save your version of that as resetghci.reg:
To make your own, open regedit and first try the same location. If not, search for WinGHCi.
You can export that subtree but you get the whole lot including recent expressions etc, which I don't think you should reset. Save that as ghcioriginal.reg just in case. Edit away all the lines except WorkingDir and save as resetghci.reg
When you double-click it it will ask you if you're sure you want to add that info to the registry. Yes you are.
Untested:
What follows works on older versions, but Microsoft seem to be going off .pif files and the start command, and I'm not able to test this in Windows 7.
Make a text file called ghci.bat in the same folder as the .reg you made. In it put
#echo off
regedit resetghci.reg
start WinGHCi
You might need to specify the full path to WinGHCi.
The start command is the windows equivalent of making a background process from a shell prompt, so this should terminate immediately.
Make a shortcut to ghci.bat (it will be called ghci.pif) and set it to open minimised and put a nice lambda icon on it (nick it from the winghci executable).
Pop that on your desktop, start menu or shortcut bar, and when you use it, you'll be popped back to your standard location.
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.