I am creating a shell-replacement for developers, which creates a new windows user, titled "developer" and only when you log into this user, should the shell be launched.
The replacement start menu is replaced with a shell based terminal with great features, the taskbar is replaces with a tree based view for windows, and the process monitor is replaced with a view where you can attach process monitors, debuggers, profiles, and memory leak detectors, etc.
I would like my application replace the regular windows shell. I have however came across a registry key that, on windows 7, works just fine. but on windows XP if I use the regular windows XP file manager the windows XP task bar from explorer.exe launches, even though I changed said registry entry!
Does anybody have any idea what it is I need to do to fully replace the windows shell AND taskbar using windows XP while still retaining use of the windows based file manager?: )
Edit:
Using C++, developing using NetBeans using Qt for my gui library. however, as I do not think this should effect the answer, I figured I would include it either way.
I believe Windows XP does not support per-user shell replacement (not sure, it's been a while since I played with the desktop stuff), but you should be able to set the 'Shell' entry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon and prevent Explorer from registering itself as the shell when it first runs. This will affect all the users in the machine, of course.
Related
I am writing a cross-platform application in C++ using Visual Studio.
My project type is the most basic one "Win32 console application".
I admit it, I haven't mastered all bits of windows software development, but there seems to be a clear pattern:
When you run an application from a CMD session, by default, Windows connects the app's default stdin/stdout/stderr with this CMD session.
(I.e. when you type 'dir' in a cmd session, it doesn't fire up a new cmd window.)
This is, however, not the case when running an application from VS. That is, when I press F5, it fires up a new console window, runs my console app inside this window and connects stdin/stdout/stderr with this console window.
What I want is instead to connect stdin/stdout/stderr with a sub-window inside the Visual Studio itself. (Akin to an "Immediate" window.)
Then I won't have to switch back and forth between VS and CMD.
Clearly, there should be some mechanisms to achieve that, since from an ordinary command prompt I could do something like:
a.exe 1>stdout.txt 2>stderr.txt <stdin.txt
I'd like Visual Studio to do something like that when running my application, but instead of files, connect the streams to a sub-window in VS.
The principal thing here is that this should be done without any modifications to the application code itself, because it must be completely independent of the development environment and/or platform.
(That's why I didn't use one of the many solutions found on stackoverflow -- they all are based on some adaptation of the application code.)
I'm porting some Qt Windows/VC++ code to Linux/GCC. The application can add it's own shortcut to the Windows Autostart folder so the application starts after login.
I want to do the same in Linux. I'm using Kubuntu 15.10 but the solution should work for virtually all (or at least most) Linux variants out there. And it should work without super user rights (or it should request the rights automatically).
I searched the web and found two solutions:
Add a desktop entry file to $HOME/.config/autostart
Add a symbolic link to /etc/init.d/
Will they both work in all Linux distributions? What are the differences? Which is to be preferred?
Also I would like to know if I should do that by programmatically running a shell command or if there is some native API I could use in C/C++ (including easy error detection).
I have put project in GitHub for managing auto-start feature in different OS. It's written in Qt.
Please check it and let me know if you have any problem using it:
https://github.com/b00f/qautostart
You can add application in various ways.
Via linux init system. For newest linux OS systemd is a standard. In this case your need to create systemd unit for your application
Via desktop manager, such as gnome, kde and possible others. In this case you need also create specification for autostarting your app.
Via bash files
I think, prefered way via systemd unit, because now this is standard way for starting process at boot time and for special user, if need.
I am creating an app for a client. It is written in 32 bit MFC using Visual Studio 2010 and run on 64 bit Windows 7 (compatibility with other versions of windows not required, it's for a very closed system on limited machines) The program will be started automatically in minimized mode when the machine boots.
The program collects data from a bunch of serial ports, and if restored, shows specifics and allows the user to change or fix things, but when minimized should just show a single "red LED" icon to show something is amiss, or a "green LED" icon to show everything is OK, no user intervention is required.
On my development machine (also Win 7-64), running the program from within Visual Studio or directly from Windows Explorer, when I change the icon using CWnd::SetIcon it changes in the window and in the taskbar, just as I want it to. If I make a shortcut to the program and start it with the shortcut, the default icon is displayed in the taskbar and will not change. Fine, it's taking the icon from the shortcut, that is explained.
The odd part is that on the target machine, no matter how I start it, including clicking on in using Windows Explorer in it's folder (like I did on my development machine), or using the Windows Registry "Run", it always uses the default icon, and never changes in the taskbar. I expected that when I used a shortcut on the desktop or in the Startup folder, since that was the behavior on my development machine.
So why would it work on one machine, when run directly from the exe, and not on another of the same windows version?
More to the point, how can I make it work on the target system? I also need to make sure that solution will work when autostarted on power-up/login.
We have an application that allows a user to drag a picture to a window and that window is a drop target (using OLE). When this code is run in the debugger and the Visual Studio instance is run as administrator (right click from desktop) then the target drop is not allowed.
If the exe is run on its own it works fine.
If the visual studio instance is run NOT as an admin the functionality works fine in the debugger. (Same solution/project files/etc)
Win7 OS. Visual Studio 2008. Unmanaged C++
I find it very odd. Not sure why it is happening. In fact I would have guessed the OPPOSITE regarding running VS as an admin.
Has anyone seen this or does anyone have links to workarounds or explanations?
This is most likely happening due to UIPI (User Interface Privilage Isolation).
In the case where you've launched your processes as Admin (due to the parent process (Visual Studio) being run as admin), UIPI isn't going to let non-elevated (admin) processes send any messages to your app. Drag and Drop between applications is implemented using Windows messages.
To work around this, you can use the ChangeWindowMessageFilterEx() API to opt into the appropriate drag and drop messages.
If you want to really and truly fix it, then you would need to
Detect when your process is running elevated
Spawn a non-elevated helper process which registers as the drop target
Pass the dropped data through IPC to the elevated process, using a method that's safe to use across privilege boundaries (i.e. no active objects which carry code)
This is a LOT of extra work when the workaround could be as simple as dropping from another elevated app (to get an elevated Explorer, just call up the File->Open dialog of any elevated app), but has the advantage that drag-and-drop will work properly if any of your customers ever run the app elevated.
Unfortunately this looks like a flaw in the OS:
http://blogs.msdn.com/b/patricka/archive/2010/01/28/q-why-doesn-t-drag-and-drop-work-when-my-application-is-running-elevated-a-mandatory-integrity-control-and-uipi.aspx
Oh well.
I find this whole issue appalling. MS has screwed up on this IMO. Essentially we can't debug an app correctly if I want to run MSVC in elevated mode (for example when I build the solution it registers COM servers).
http://social.msdn.microsoft.com/forums/en-US/windowsuidevelopment/thread/2fa935cf-be57-4bcc-9b96-7ee5a6b2b7a5/
I'm trying to debug shell extension (IContextMenu) in Windows 7 with Visual C++ 2008. I have set DesktopProcess=1 in the registry and set host app to explorer.exe. But when I start the debugger, it launches explorer.exe and then detaches from the process. DllMain of the shell extension isn't called.
The same code with exactly the same settings launched in debugger without any problems in Windows XP + Visual C++ 2008.
Any thoughts how to debug the shell extension in Win7?
I've found a nice workflow that I think is the fastest way to rapidly iterate the code-build-test cycle when developing shell extensions. The following should work on any Windows version.
First prepare - set the start program of your shell extension project to be c:\windows\explorer.exe and also set it to be the start-up project.
Then, whenever you want to debug your shell extension perform the following steps:
Click on the task bar and press Alt-F4 - this will bring up the shut down dialog
Press Ctrl-Alt-Shift-Escape - this combination will close explorer.
Use Alt-Tab to go back to Visual Studio and press F5 - explorer will now launch with the VS debugger attached to it from the very beginning.
When done, just stop the debugger session. This will kill the debugged instance of explorer and will also automatically start a normal instance of it. This will also unlock the shell extension DLL so that you can build it again.
Caveat on Vista and 7 - be sure to run the Visual Studio that you use for debugging in non-Administrator mode (non-elevated), so that the explorer is started in its usual non-elevated mode.
Try launching explorer and THEN attaching the debugger to it.
You could try putting a DebugBreak() call in your code. This should launch the just-in-time debugger at the call and give you an idea of what is going on.
You should take a look at gflags.exe, part of the standard debugging tools sdk. It's got all the options you need to configure (global)flags for any process startup/services/heap/pool-tagging/stacktrace's-on-allocation etc...
Debugging Explorer.exe is usually overkill for extensions that operate in a shell view.
I personally use a little app I made that hosts an instance of IExplorerBrowser similar to this example. If your IContextMenu item is not the default item then you can just use Notepad.exe and its open file dialog...