I'd like to write my own (very simple) explorer.exe alternative that I could actively switch between without having to restart my computer.
Is it possible to run two shells simultaneosly (or to write a program that temporarily disables the current shell)?
If not, is it possible to stop explorer without it restarting itself, and have my shell start itself instead?
Edit
More info: I'd like to write a simple productivity tool for myself. I want to set up a very simple task manager that prevents me from starting/opening/using anything but a whitelisted set of applications I list ahead of time. Locking me into that set of apps for whatever time period I've set. If there's another (better) way to prevent people from shutting down my app, switching from my app (with alt-tab, etc) I'm all ears.
Note: I'm fine with the app/shell/whatever being escapable by restarting my computer. I just want to make it massively inconvenient to switch to being distracted, and I wanted to learn a bit more about the Windows API.
See this question for details about writing a shell.
No, there can only be one real shell process (SetShellWindowEx only works when there is no other shell process) WH_SHELL can be used by other processes and it might be enough for your needs (Maybe in combination with IShellExecuteHook)
When explorer.exe is started and it detects a different shell it will not display the taskbar, just a file browser window. Explorer also looks at the shell value in the registry IIRC. You might also want to look into the shift to exit trick.
Related
I have little previous experience with Windows (for programming, anyway), but recognizing that Windows has an enormous market share, I am trying to support it in my programs (even though they are just for fun, I like to pretend they're big projects). I have written a tiny shell with minimal (and when I say minimal, I mean minimal) features.
I am trying to port it to Windows and would like to use it independently from cmd.exe in a Win32 Console window (meaning the shell part of cmd.exe isn't running at all, but the window used for it shows). I have already done most of the other porting stuff such as build system (CMake) and changing appropriate Unix syscalls to Windows ones in a #define. I have done a little research and found little on this topic, however. I know it is possible because I've seen it done with Bash. Visual Studio also used to do it when I ran a program in its GUI.
Reference article I got some of this info from: https://en.wikipedia.org/wiki/Win32_console
Note: What I mean is when you click on it and it opens it without running cmd in its own little console window. Or when you type it into cmd it opens in a separate window that isn't running cmd. I am assuming cmd.exe and the console window it runs in are two separate things, but if I am wrong, please let me know. :)
This question is inspired by https://askubuntu.com/questions/111144/are-terminal-and-shell-the-same and a similar question where I got that Wikipedia link. Someone said that the console window and the shell were separate. I was writing my own shell so I started to wonder how to make mine independent of the default one.
The Win32 Console and cmd.exe are two different things. Windows automatically opens a console window when a program that needs one is started. It decides whether do to so by switches hard-wired into the executable. This window will be running said program. If the program that started the process is running in a console window, the two programs will share that console window.
As Noodles said, it really is that simple. You just start it. Double-clicking on it will do it. The CreateProcess() function with CREATE_NEW_CONSOLE passed to it will do it. Running the program from cmd.exe with
start <command>
will do it.
There is also a family of functions in the Windows API, called FreeConsole() and AllocConsole() that will free a program from its current console and create a new console for it, respectively.
Reference link (given by Noodles): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).aspx
Is it's possible to detect inside app from where it was run? From cmd/bash or from GUI? Assume that we are working in graphical mode, not in pure console.
Not really, but sort of. Short answer: better not to try, get the user to tell you via an argument, which you can pre-fill in a shortcut.
Long answer:
In both cases, the program is launched in a similar way: the shell application (whether cmd/bash or Windows explorer/whatever gui launcher linux has) call CreateProcess or ShellExecute on Windows or fork+exec on Linux and the way the user executed it gets lost.
However, the process does have a parent ID which might be useful.... but it isn't reliable either for a few reasons: telling if it is a gui or command line shell isn't easy (best you can do is look at the image name) and the parent might terminate as soon as you launch, so there'd be no parent! (Linux gui apps often fork themselves to detach from the terminal. Of course, if you do this you'd probably know, but if you use a library it might happen without you realizing it.)
Well, the fact that I'm going off on parenthetical asides after every sentence shows how unreliable and complicate that is. If you want to try though, looking at your parent process ID before doing any fork/detaching might be helpful.
BTW looking for a parent console isn't very helpful: a Windows GUI subsystem program won't attach to the parent console even if one exists and a Linux GUI program may attach to the controlling tty of the X window manager.
What I'd actually recommend though is passing an argument to your function to tell it how it got started. When you create the GUI shortcut, make it automatically pass the "started by gui" argument to you. Then you can check args for it and react accordingly.
It still isn't perfect, but it is fairly easy to implement and probably good enough - gui launchers would probably use a shortcut anyway and you can pass arguments through them, so the user doesn't need to know about how it is implemented.
Or you could install two programs, one which is convenient from the command line and one which is optimized for the gui environment.
But I think that's the best you can do.
I have a batch script (yes I know batch is awful, no I don't care) that checks my VM's on the local machine to the ones stored on my USB, if they're out of date, it updates them, then boots them. I use multiple machines at uni, so this makes it easier to ensure the VM I'm working on are always the latest.
When I open them like this;
PATH "%PROGRAMFILES%\VMware\VMware Workstation\"
START vmware.exe -x "%USERPROFILE%\Desktop\VMs\VM1\VM1.vmx"
START vmware.exe -x "%USERPROFILE%\Desktop\VMs\VM2\VM2.vmx"
START vmware.exe -x "%USERPROFILE%\Desktop\VMs\VM3\VM3.vmx"
It causes the VM's to open in separate windows, rather than tabs of the same window for easy switching.
The workaround I came up with is to boot the VMware program first, then when I open the .VMXs, they all open as tabs in the same window.
The problem is that the VMware program sometimes takes a long time to open. Similar to Photoshop's loading splashscreen, but instead with no visual indicator, VMware opens up to 20 seconds after the icon has been clicked, or it has been summoned with a script.
So finally, here is my question.
Is there a way to make a batch that waits for the program to open before continuing? I know by omitting START I can stop the batch until the program closes, but obviously this is useless for my purposes.
If all else fails, I may just have to include a 30 second timeout and hope it's enough.
I don't think there's any reliable way to do this.
If you have a program that you need to open and then wait for a certain state to change in the program before doing something else, that state could be set by any arbitrary operation running on any thread spawned by the application. There would be no way to know when the application had set that state unless you were able to somehow communicate with the program to query or be notified of its state.
Theoretically if you knew enough about what the program was doing internally you could monitor the thread count or file system accesses or something to determine roughly when it had changed to the desired state, but just using a timer would be much much simpler.
I decided to write a program in RUBY in which the following things should be done:
1 - this program must run a specific program (for example utorrent) at a specific time (for example 1 pm).
2 - this program must turn off my computer at another specific time.
I don't have any idea about the algorithm and manner of writing such program.
One of the easiest ways to do this is to simply send kill signals to the processes, requesting the app shut down normally (Linux), or in Windows use taskkill.
To shutdown a machine in Windows, you can use shutdown /s /f which forcibly closes any programs that are running, and turns the computer off.
No matter which way you do it, you'll basically be running the enter link description heresystem() command in Ruby, which runs command line commands. To make your app portable, you simply look up how to do these tasks in each target OS, and you're done.
Two more alternatives that work the same as your Ruby proposal, but which are not as easily portable:
Write a batch file in Windows that calls taskkill, or a bash script on Linux. Unless the program in question provides a specific way to shut it down via its own command-line parameters, this should work for any/all applications.
You can also use Task Scheduler in Windows, or cron in Linux to do the same thing.
Many Windows apps (like Skype or MSN for instance) don't let you start multiple instances, rather trying to run it a 2nd time just leaves the existing version running.
Is this typically done in some simple way - the start-menu shortcut is a 'wrapper' app around the main app - or is there some registry magic you can do to delegate the problem to Windows itself?
Specifically dealing with Win32 here (unmanaged C++) but happy to hear more general solutions as long as they are workable on Windows XP or later.
EDIT: this seems the best duplicate.
Named Mutex or similar OS-specfic named object. If it exists - app is running.
Lock file somewhere (in temporary directory, etc - create it on program start, remove on program end). Linux software frequently operates this way (some programs store PID in lockfile), but it isn't safe - if you suddenly lose power (electricity cut off), it is possible that lock file won't be deleted.
And you can always enum all running processes and try to find yourself.
There could be more ways to do it, but those are the first ones I could think of.
As far as i remember, there exist system-wide Mutexes. Set Mutex on first launch, if on launch already set, immediately exit.
Use CreateMutex() call an prepend the name with "Global\" should to the trick.
I just check to see if the process is already running: if it's not start the application, if it's already running bring the window to foreground. The check is done in the Main method.
I get the process name with System.Diagnostics.Process.GetCurrentProcess().ProcessName and check if it's already running System.Diagnostics.Process.GetProcessesByName(). If there are more than 1 processes focus the first of them and then exit.