The problem
I'm trying to open a URL in internet explorer. Regularly I would use the Navigate method of the Internet Explorer com object. However that isn't available in the programming language I am using (MapBasic).
My next method would be to use the Shell function to execute a command in the command line. For example:
explorer "http://yahoo.com"
Will navigate to http://www.yahoo.com. However when it comes to longer links, e.g.
https://www.google.co.uk/imgres?imgurl=http%3A%2F%2Fclv.h-cdn.co%2Fassets%2F15%2F22%2F768x518%2Fgallery-1432664914-strawberry-facts1.jpg&imgrefurl=http%3A%2F%2Fwww.countryliving.com%2Ffood-drinks%2Fa35552%2Ffacts-about-strawberries%2F&docid=kWdFoElV3zVDpM&tbnid=2gR8XfYaBJZV1M%3A&vet=1&w=768&h=518&hl=en&bih=813&biw=1461&q=strawberries&ved=0ahUKEwiV--LfsPbQAhWaHsAKHUfaC2EQMwg0KAMwAw&iact=mrc&uact=8
Command prompt actually navigates to:
https://www.google.co.uk/imgres?imgurl=http%3A%2F%2Fclv.h-cdn.co%2Fassets%2F15%2F22%2F768x518%2Fgallery-1432664914-strawberry-facts1.jpg&imgrefurl=http%3A%2F%2Fwww.countryliving.com%2Ffood-drinks%2Fa35552%2Ffacts-about-strawberries%2F&docid=kWdFoElV3zVDpM&tbn
Which is a significantly shorter URL.
To solve this issue I am looking into using the Win32API, but I can't for the life of me figure out how I could run this code with Win32API... Perhaps using Shell32.dll's ShellExecute? Or would it be better to use Kernel32.dll's CreateProcess?
Whichever is used, it would be really helpful if someone could supply me with some example code of how to open the above link with IE using the Win32 APIs in VB/C#. I can easily port the code to MapBasic from there!
(Alternatively if there is a method to open the link through shell, I would love to know how!)
Thanks
You can just "execute" it using Process.Start which is under System.Diagnostics name space.
As Hans Passant replied:
It is 259 characters long. Magic number. Don't use Explorer.exe, use a
browser like iexplore.exe
This is exactly the solution I needed. Using iexplorer.exe instead:
"C:\Program Files\Internet Explorer\iexplore.exe" "https://www.google.co.uk/imgres?imgurl=http%3A%2F%2Fclv.h-cdn.co%2Fassets%2F15%2F22%2F768x518%2Fgallery-1432664914-strawberry-facts1.jpg&imgrefurl=http%3A%2F%2Fwww.countryliving.com%2Ffood-drinks%2Fa35552%2Ffacts-about-strawberries%2F&docid=kWdFoElV3zVDpM&tbnid=2gR8XfYaBJZV1M%3A&vet=1&w=768&h=518&hl=en&bih=813&biw=1461&q=strawberries&ved=0ahUKEwiV--LfsPbQAhWaHsAKHUfaC2EQMwg0KAMwAw&iact=mrc&uact=8"
Opens the URL fine.
Similarly one can also use the following command:
start iexplore "https://www.google.co.uk/imgres?imgurl=http%3A%2F%2Fclv.h-cdn.co%2Fassets%2F15%2F22%2F768x518%2Fgallery-1432664914-strawberry-facts1.jpg&imgrefurl=http%3A%2F%2Fwww.countryliving.com%2Ffood-drinks%2Fa35552%2Ffacts-about-strawberries%2F&docid=kWdFoElV3zVDpM&tbnid=2gR8XfYaBJZV1M%3A&vet=1&w=768&h=518&hl=en&bih=813&biw=1461&q=strawberries&ved=0ahUKEwiV--LfsPbQAhWaHsAKHUfaC2EQMwg0KAMwAw&iact=mrc&uact=8"
Which should be less system dependant.
As a fun little project, I am trying to use C# to operate the bash.exe provided by Git. I want the process to behave just as if I ran it in the Git Bash Application. By this, I mean I want to be able to execute command and get the output of said commands (i.e. if I enter the command "curl --version", I want to get the same output as the image here and be able to store it in a variable)
I have come very close to accomplishing this with the code here. However, with some commands, I find that the Process in C# never terminates. For example, if I try to execute the command "curl --help", I find the the Process never exits where "curl --version" did. As a quick hack, I figured out that I could fix this by changing the command to
curl --help >> output.txt
and then reading the .txt file. This does cause the command to exit and to write the correct output to the file, however, I don't like having to do this and I am sure there is a better solution to make commands of this sort exit properly. Thanks for the help!
Last time I used XPerf it killed my SSD, too much disk activity.
Is there an easy way to make XPerf write its trace data to an alternative hard drive?
I am using the script HeapMonitor.cmd to start up XPerf, so I am guessing there are some command line options for XPerf that will do what I need?
I haven't tried this but maybe you can work it out with a combination of absolute paths for ProfileFileName in -start and MergedETL in -stop -d ?
Here's a link to the command line parameter help.
OK, so the answer is simply to move the HeapMonitor.cmd file to the other hard drive (non SSD) and it will just work.
There are command line options which look like this,
-f heap.etl
which could be changed to
-f f:\blah\heap.etl
I have done some of them, but not all of them, and it still seems to work.
I would post a snippet, but I honestly have no idea what part of my code could possibly be doing this. The program is sizable, I don't want to make you all wade through it. What kinds of things could possibly be the cause of this? Everything works perfectly when called from the command prompt: "readoo.exe". But when I click the exe in its file. . . "readoo.exe has encountered a problem and needs to close. . ."
this is intended to eventually be a scheduled task -> i'm worried, will it work?
i've never debugged, all i've ever used is notepad. I am learning, and feel that this strengthens my understanding of a project.
it crashes nearly immediately. there are no shortcuts, though the file paths are relative.
trying this method: shortcut -> properties -> shortcut -> Start In. I don't have a "shortcut" option
my program reads log files, parses, and creates 4 new files based on the found content
Microsoft Error Report says file not found. But how can this be? the files are there, albeit relative.
Take a copy of your project, and then start hacking bits out of it. When it no longer crashes, you've removed the bit causing the problem.
At what point does it fail when you double-click on it? Immediately, or only when you take a certain action?
You could also add a lot of logging to it, which could indicate where the problem is too.
This is probably looking for a dll that it can't find or is finding a different version from what it wants.
You could try Process Monitor or Process Explorer from sysinternals to see what dlls it loads when it does work and where it finds them.
Try putting a System.Diagnostics.Debugger.Break()call as the first thing in Main() and you'll be asked to attach a debugger - this should definitely show you what is different betweent the 2 invocations.
I would start with identifying what is different in the two methods of execution. Is there a shortcut modifying anything?
The starting directory?
The execution account?
command line arguments?
There are 2 things that it could be:
The current directory could be different when you click on the program or run from the command prompt.
The settings and path could be different when you click on the programe you are using the standard command prompt, are you opening the visual studio command prompt when you run the program from the prompt.
If your application relies on some file that should be on the same path of that exe, that can occurr.
You will have to change the properties of the exe (or shortcut to the exe) to "Start In" the directory where your exe is. For a shortcut, right click on the shortcut -> properties -> shortcut -> Start In.
I guess that is what I think could be the cause.
EDIT: Add a Console.ReadLine towards the end of your code to make it pause for you to see any exception thrown. That should help when you run it using windows explorer.
Put a try/catch around your code and output the exception message to the console in the catch block. That should give you some clues.
My application throws 'Access denied' errors when writing temporary files in the installation directory where the executable resides. However it works perfectly well in Windows XP. How to provide access rights to Program Files directory in Windows 7?
EDIT:
How to make the program ask the user to elevate rights? (ie run program with full admin rights)
Your program should not write temporary files (or anything else for that matter) to the program directory. Any program should use %TEMP% for temporary files and %APPDATA% for user specific application data. This has been true since Windows 2000/XP so you should change your aplication.
The problem is not Windows 7.
You can ask for appdata folder path:
string dir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
or for TEMP path
string dir = Path.GetTempPath()
Your program has to run with Administrative Rights. You can't do this automatically with code, but you can request the user (in code) to elevate the rights of your program while it's running. There's a wiki on how to do this. Alternatively, any program can be run as administrator by right-clicking its icon and clicking "Run as administrator".
However, I wouldn't suggest doing this. It would be better to use something like this:
Environment.GetFolderPath(SpecialFolder.ApplicationData);
to get the AppData Folder path and create a folder there for your app. Then put the temp files there.
Options I can think of:
Run entire app as full admin priv. using UAC
Run a sub-process as full admin for only those things needing access
Write temporary files elsewhere
Add new item in the project: Application Manifest and save it.
Now open this file and look for <requestExecutionLevel>. It must be set to asInvoker.
Change it to highestAvailable. Now on executing your application, a prompt will appear asking for permission. Click yes!
Thats all :) now you can write and read from the system32 or any other file which requires admin right
You can verify your application by sigcheck.
sigcheck.exe -m yourapp.exe
And in the output check for element requestedExecutionLevel.
Another way round it would be to stop UAC then restart it. Create a CMD file with the following code;
Rem Stop UAC
%windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
rem force reboot
Start ShutDown /R /F /T 30
You'll need to right click on the CMD file and use run as admin. once you have finished what you are doing restart UAC with the following code (no need to use run as admin this time);
%windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f
rem force reboot
Start ShutDown /R /F /T 30
The down sides to using this method is have to right click and use run as admin to close UAC down and you have to reboot for it to take effect.
BTW there are several reasons why you would need to write to the forbidden areas...the first two that springs to mind would be to run a batch file to append host to prevent your browser going to dodgy sites or to copy license keys in a silent install.
You can't cause a .Net application to elevate its own rights. It's simply not allowed. The best you can do is to specify elevated rights when you spawn another process. In this case you would have a two-stage application launch.
Stage 1 does nothing but prepare an elevated spawn using the System.Diagnostics.ProcessStartInfo object and the Start() call.
Stage 2 is the application running in an elevated state.
As mentioned above, though, you very rarely want to do this. And you certainly don't want to do it just so you can write temporary files into %programfiles%. Use this method only when you need to perform administrative actions like service start/stop, etc. Write your temporary files into a better place, as indicated in other answers here.
I cannot agree with arguments, that it is better to write all files in other directories, e.g., %APPDATA%, it is only that you cannot avoid it, if you want to avoid running application as administrator on Windows 7.
It would be much cleaner to keep all application specific data (e.g. ini files) in the same folder as the application (or in sub folders) as to speed the data all over the disk (%APPDATA%, registry and who knows where else). This is just Microsoft idea of clean programming. Than of course you need registry cleaner, disk cleaner, temporary file cleaner, ... instead of e+very clean practice - removing the application folder removes all application specific data (exep user data, which is normally somewhere in My Documents or so).
In my programs I would prefer to have ini files in application directory, however, I do not have them there, only because I cannot have them there (on Windows).
I think there is an alternate solution to all these problems....
Make an two level application. As said above...
1) Launcher which will launch another Main App using code such as (VB)
Call ShellExecute(hwnd, "runas", App.Path & "\MainApp.exe", 0, 0, vbNormalFocus)
2) Main App, which is writing to protected areas, ie Program Files folder
I've successfully tried this with windows 7
I'm also developing an app which has online update feature. But it doesn't work in Vista/W7..
I agree with other peoples about Microsoft Policies and Standard Practices.
But my Question is ..
1) How to apply update to an existing application, which probably always remain in Program Files folder.
2) There might be some way to do this, otherwise how goolge updater, antivirus updater or any software updater workes?
I need answer to my questions..... :o
Prof. Rajendra Khope
(MIT, Pune, India)
If you have such a program just install it in C:\, not in Program Files. I had a lot of problems when I was installing Android SDK. My problem got solved by installing it in C:\.
I was looking for answers. I found only one.
None of these work for me. I am not trying to write temporary files, unless this is defined as nonsystem files. Although I am designated the admin on my user profile, with full admin rights indicated in the UAC, I cannot write to program files or windows. This is very irritating.
I try to save an image found online directly to the windows/web/wallpaper folder and it won't let me. Instead, I must save it to my desktop (I REFUSE to navigate to "my documents/pictures/etc" as I refuse to USE such folders, I have my own directory tree thank you) then, from the desktop, cut and paste it to the windows/web/wallpaper folder. And you are telling me I should do that and smile? As an admin user, I SHOULD be able to save directly to its destination folder. My permissions in drive properties/security and in directory properties/security say I can write, but I can't. Not to program files, program files (86) and windows.
How about saving a file I just modified for a game in Program Files (86) (name of game) folder. It won't let me. I open the file to modify it, I can't save it without first either saving it to desktop etc as above, or opening the program which is used for modifying the file first as admin, which means first navigating all the way over to another part of the directory tree where I store those user mod programs, then within the program selecting to open file and navigate again to the file I could have just clicked on to modify in the first place from my projects folder, only to discover that this won't work either! It saves the file, but the file cannot be located. It is there, but invisible. The only solution is to save to desktop as above.
I shouldn't have to do all this as an admin user. However, if I use the true admin account all works fine. But I don't want to use the real admin account. I want to use a user account with admin rights. It says I have admin rights, but I don't.
And, finally, I refuse to store my portables in %appdata%. This is not how I wish to navigate through my directory tree. My personal installations which I use as portables are stored in the directory I create as a navigation preference.
So, here is the tried and true answer I have found:
From what I have seen so far.... unless one uses the real admin account, these permissions just aren't ever really available to any other user with admin privileges in the Windows Vista and Windows 7 OS's. While it was simple to set admin privileges in Windows XP, later versions have taken this away for all but those who can comfortably hack around.
While M$ "best practices" is to not write data into the %programfiles% folder; I sometimes do. I do not think it wise to write temporary files into such a folder; as the TEMP environment variable might e.g. point to a nice, fast, RAM drive.
I do not like to write data into %APPDATA% however. If windows gets so badly messed up that one needs to e.g. wipe it and reinstall totally, perhaps to a different drive, you might lose all your settings for nearly all your programs. I know. I've done it many times. If it is stored in %programfiles%, 1) it doesn't get lost if I e.g. have to re-install Windows on another drive, since a user can simply run the program from its directory, 2) it makes it portable, and 3) keeps programs and their data files together.
I got write access by having my installer, Inno Setup, create an empty file for my INI file, and gave it the users-modify setting in the [Files] section. I can now write it at will.
I am working on a program that saves its data properly to %APPDATA%, but sometimes, there are system-wide settings that affect all users. So in these situations, it HAS to write to the programs installation directory.
And as far as I have read now, it's impossible to temporarily get write access to one directory. You can only run the whole application as administrator (which should be out of the question) or not be able to save that file. (all or nothing)
I guess, I will just write the file to %APPDATA% and launch an external program that copies the file into the installation folder and have THAT program demand admin privileges... dumb idea, but seems to be the only practical solution...
You can add an access to IIS User for folders of Website or Web Application that you want write or rewrite in it.
It would be neater to create a folder named "c:\programs writable\" and put you app below that one. That way a jungle of low c-folders can be avoided.
The underlying trade-off is security versus ease-of-use. If you know what you are doing you want to be god on you own pc. If you must maintain healthy systems for your local anarchistic society, you may want to add some security.