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.)
Related
In debugging C++ application in Visual Studio IDE in Windows, is it possible to have the application start in the terminal that comes integrated as a window pane at the bottom of the IDE? At present, hitting F5 to start debugging force starts an external console application.
See image gif attached:
You will notice that a new external console opens on the side. The bottom right of the IDE has a "Developer Powershell" pane. Can the application be debugged within this pane?
Flavors of this question have been asked before. However, they seem to have received conflicting answers with no clarity. See for instance, this thread on SO.
Few websites claim that this is possible and seemingly provide tutorial to accomplish this. For e.g., see here. However, this seems to be .net applications and not C++ applications.
Even using VSCode (a different environment), it seems impossible to start a C++ debugging session in Windows inside the IDE itself. See question/answer about this here. It appears that an external new console will necessarily be launched.
I just built one of the project templates Visual Studio 2012 offers (the 'Split App (XAML)' template accessible via Templates -> Other Languages -> Visual C# -> Windows Store in the 'New Project' dialog).
I can execute the application from Visual Studio 2012, and I can launch it from the Windows 8 start screen - but if I attempt to launch the generated executable directly (e.g. via the Windows explorer or from a command shell), a full-screen error message is printed saying "This app can't run on your PC".
Looking at a running instance of the application via Process Explorer shows that it a) just links against the .NET runtime MSCOREE.DLL and b) it gets invoked with a command line like this:
"[..] \bin\Debug\AppX\WindowsStoreSample.exe" -ServerName:App.AppXgsxd2athqtr03f55we0938hcn632we3k.mca
My actual question is: what's the correct way to launch this kind of application programmatically? Would I use plain CreateProcess and then try to assemble a command line like shown above? If so, how could I determine the correct -ServerName argument? Or is there some other way to launch such applications?
The correct way to launch Windows Store apps is to use the IApplicationActivationManager interface. This is also what Visual Studio itself uses for launching the application. All methods on the interface have a DWORD out parameter which gets you the PID of the newly launched process.
I am building a C++ Console Application which makes some OpenGL printing.
The entire thing is done by glut and gl libraries. My new goal is to add some Windows Forms to the project so one could "configure" the 'game' with some textbox and other controls provided by VS before the console appliction starts.
I know that the best solution for the current problem is to add Win32 API, but I don't know how to integrate console application project with win32 API alltogether.
I know that in C# it's done quite easily with the .ShowDialog() command.
Although launching a window from a console application is perfectly doable, that window will not be responsive, because your console application does not have a message queue. (Or rather, it has a message queue, but it is implemented by code that you have no control over.) So, you can open up a window, draw in it, and force it to manually update, but you cannot receive user input in it.
I would suggest that you forget about doing it this way, and you write a little windowed application instead, which prompts for the configuration and then launches the console application passing it the configuration as command-line parameters, or fills-in a configuration file for the console application to read.
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...