I understand that desktop/GUI apps are not supported in Windows containers. They do run but there's no built-in way to interact with them. I had the following idea - maybe I could use the Desktop Sharing API (https://learn.microsoft.com/en-us/windows/win32/api/_rdp/) for this purpose, the idea is to run a desktop app, then run a sharing program that uses the Desktop Sharing API, and connect to it using a Desktop Sharing API viewing program from the host.
I had to do some recap about window stations and desktops, and I noticed that when starting the container with cmd in interactive mode, I'm logged with ContainerAdministrator as a service (logon type 5). I tried running some WinAPI functions that deal with desktops and winstation and got some access denied results, so I switched to running cmd as system.
The window station of the cmd process (and other child processes) is not the interactive WinSta0, but instead some other service window station, which makes sense since I'm logged on as a service, and I figured that I can't use this window station, so I used a little program I wrote to run notepad in Winsta0 in the Default desktop. Afterwards I ran another program that enumerates the windows on WinSta0\Default, and the notepad window does get enumerated and I also get it's title, so it's running somewhere.
So now I tried running the desktop sharing API program (also on WinSta0\Default). It runs and I can connect from the host, but I only get a black screen without anything on it. I also tried running a program that takes a screenshot of the windows but I get an empty bitmap.
So I thought maybe the Default desktop is not the active desktop, and by using the OpenInputDesktop function I could confirm it - the current desktop was the Winlogon desktop, so I used the SwitchDesktop function to switch to the Default desktop (I used OpenInputDesktop again to verify that it actually worked).
Unfortunately, this didn't change anything, I still get an empty screen and empty bitmaps.
I know that containers are built for micro services and are not supposed to run GUI apps and so, but still - is there a way to make this work? Or any ideas of what else I can check? Alternatively, if you know that it can't work - I would also be happy to hear a good technical explanation of why it doesn't work.
Related
I have a small warp server project on Windows that listen to a particular port and do something whenever I send a command to it by REST (for example: POST http://10.10.10.1:5000/print). It's a small client for printing PDF / receipt directly from another computer.
It works. But my problem is when I had to package the whole project, the Rust compiler give me an executable file (.exe). The application displays a terminal window when I run it. I want this terminal to be hidden somehow.
I try to run the program as a windows service (by using NSSM). It doesn't work for me since I had to access the printer. Windows doesn't allow my app to access any devices or any other executable as a windows service. (The reasons are explained here: How can I run an EXE program from a Windows Service using C#?)
So I plan to run my app as a tray-icon application so user can control or close the app. (https://github.com/olback/tray-item-rs)
Unfortunately, I still cannot hide the app's terminal window.
Another solution that I found is hstart (https://www.ntwind.com/software/hstart.html). But I would like to use this as "the last resort" solution since many antivirus/windows defender mark it as a malware.
Do anyone know how to hide or get rid of it ?
After lot of searching, It turns out to be easier than I thought. Just add
#![windows_subsystem = "windows"]
on top of your main.rs file. (for rust > 1.18) and the terminal is gone.
These control the /SUBSYSTEM flag in the linker. For now, only
"console" and "windows" are supported.
When is this useful? In the simplest terms, if you're developing a
graphical application, and do not specify "windows", a console window
would flash up upon your application's start. With this flag, it
won't.
https://doc.rust-lang.org/reference/runtime.html#the-windows_subsystem-attribute
https://blog.rust-lang.org/2017/06/08/Rust-1.18.html
https://learn.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=msvc-170
I try to run an windows 10 application inside a windows servercore container.
The app can run without user input via COM-Interface (and without visible GUI), but it seems that it needs to load a hidden window in the background. When I start it on docker, the application log file indicates that it's stuck on starting this window.
Is there a way to make the app assume it successfully loaded the window?
All information I found so far was about users who want to see the GUI or about Linux/Windows combinations. None of that helped me.
I need to run a GUI script (AutoHotKey, which makes mouse clicks and press keys) on:
A different windows user (i.e. I run the script, then switch user
while keeping the session active)
A remote Amazon windows server (using remote desktop) where I also
run the script then close the Remote Desktop while keeping the
instance running
Unfortunately, in both cases, the script doesn't run as it seems that Windows enters a "GUI-less" mode where all GUI components are not active anymore.
Is there any solution to this?
Any hint would be greatly appreciated as I've now lost days trying to solve this!
Many thanks, Thomas
I do not believe this is possible due to the way Remote Desktop is implemented. When you close the RD connection, the GUI is no longer drawn. Therefore, AutoHotkey is unable to perform mouse clicks and key presses.
A possible workaround would be to make some registry tweaks (if possible on your server) which allow GUI interaction while minimized.
Locate HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
Create RemoteDesktop SuppressWhenMinimized as DWORD with a value of 2
Registry Tweak Source
Ok, this is a tricky one. I'm trying to set up a Selenium Grid 2 with some Windows 7 VMs to run Webdriver tests. To automatize the whole process I use some ant script that connects to the VMs through ssh to start/stop/reconfigure the nodes.
Everything works great, the nodes can register with the hub host and execute the test. Only problem is that I don't see any browser window during the test run. I can see the process and I see the test log being executed, but there is no graphical interface.
On the other hand, if I start the node manually through Windows, everything is normal.
I suppose the problem is that processes executed under cygwin cannot start Windows displays, but in that case, shouldn't throw an error? The other option I'm thinking is that Webdriver is using HTMLunit as a fallback, but then... why do I see the firefox process as long as the test lasts and consuming CPU and memory?
Through ssh, you only exchange with Windows stdin, stdout and stderr streams. The ssh connection is tunneling those streams and nothing else. You don't see Windows Desktop interface, but the Desktop object exists on the Windows machine, the programs (here the browsers) are connected to it, and all GUI interactions are live in there.
If the GUI doesn't require any user interaction, everything is fine that way. The dialog boxes are created, the program runs, once it finishes, the dialog boxes are destroyed by the application and the application closes. Nothing is blocking in terms of GUI our application.
If you program requires an user action in the created yet invisible dialog boxes, your program will be there waiting for your interaction to move forward. You will see the process in the task manager, doing nothing but waiting. As you don't have access to the Windows Desktop where the dialog boxes are created and virtually 'displayed', the program seems to hang.
A typical case 2 is if you remote run a program waiting for a user to do something, say notepad. You can launch notepad, it will be spawned and then it will wait for you to type some text or close it.
With your Selenium tests, you are in case 1: all the browsers' interactions needed to make the GUI working are actually done by Selenium server that does the navigation clicks and the program exit for you. Their GUI actually are living by browsing through your test web servers, you just don't see it.
Some further readings from Microsoft website on Desktops and Desktop Creation.
If you want to see the tests and have valid screenshots, you need to have a user logged in and those tests need to run as that user. Everything must run through that single desktop session, so you cannot use RDP to remotely connect to the machine. Your best bet is to use VNC, since that will connect to an already established session.
Suppose you have a process which run as as service as the System Account, is it possible to view the content of the windows created by the processes created by the service.
Suppose for example, that you have a service running as a kind of wrapper which starts Excel.
Microsoft Spy++
Select Spy/Processes and find your process there
If some of it's threads had created any windows, you'll see them as subtrees.
A process that creates and fills windows should never be run as a service. That being said, if this is on Win2K3 or earlier set the service to interact with the desktop and you can see the contents yourself. If it is on Vista or later there is no way to examine the contents of an arbitrary window.
If it is a specific type of window (i.e. EDIT control) that supports retrieving its contents you may be able to run another service that sends a windows message to the first service to get what you want.
Services will (under normal circumstances) be associated with a different window station to the interactive desktop, and they cannot interact -- you can read up more on Window Stations on MSDN