Is there a Windows API call to change a terminal session's video mode, in a manner not dependent on INT 10H? (I specifically need to get to video mode 3 -- saving the old version of the screen, and removing scrollback, in the process, but it'd be pretty interesting if others are available as well.)
The Windows version of dos.h no longer includes the REGS union or the INTCALL macro, so I'm guessing it's deprecated in favor of some new approach.
Changing to a legacy video mode first requires support to go into full-screen mode with the console window. That support has started disappearing a long time ago. I can't quite remember the last machine I had that still allowed it but it was in the previous century.
There's a quick way to find out. Open a console window and press Alt+Enter. If nothing happens (like on a 64-bit OS) or you hear a loud beep then it won't be possible. Keep in mind that even if it does, few users still have machines where it works.
Move ahead with this by programming DirectX. Or just a GUI app, they are not hard to slam together these days.
Related
I am trying to write a simple console application for Windows 10 that changes the screen brightness. Ultimately, I want to use this application with AutoHotKey, but this is secondary.
In researching this, almost everything I found referred to Android, which doesn't help. I did find this Q&A about changing the screen brightness with C, but unfortunately that is for Linux.
This archived thread contains a script that (while appearing quite hacky) makes a good impression - but it
is deprecated, and on many [Systems] it will not return the full brightness settings array. So, where you should have 8 levels, IOCTL_VIDEO_QUERY_DISPLAY_BRIGHTNESS will only return 6, or none at all. (by jkiel, 1)
So I would prefer to use the WmiMonitorBrightness class (2 3) over IOCTL_VIDEO_QUERY_SUPPORTED_BRIGHTNESS. It also provides a lot finer granularity, but I lack the skills to implement it correctly.
So how can I change the screen brightness on Windows 10? Possibly using the mentioned WmiMonitorBrightness class? I don't mind if it is a C application, an AutoHotKey script or something else, that I can control from console.
Looking for a solution, I found this software from 2008 which works like a charm for me on Windows 10. The developer provided the C# source and compiled application here. "You will need the Microsoft .NET Framework 2.0 or greater for the app to work."
Plus it supports the full granularity of setting brightness on your screen.
To use the console app, the following parameters are allowed:
DisplayBrightnessConsole.exe
This will return the current brightness level.
DisplayBrightnessConsole.exe -getlevels
This will return all possible brightness levels accepted by the display, separated by a new line.
DisplayBrightnessConsole.exe 20 (or some other brightness level number)
This will set the brightness level of the display to the parameter given, in this case, 20.
The code currently only works on single-display systems. If your system has more than one display, it
will only work on the first (generally primary) display. It should be fairly easy to modify it to support more.
Possibly helpful for people using python - but it doesn't help in my specific case:
How can I detect brightness changes using Python and WMI on Windows 10?
I'm ready to outsource the screen capture functionality of our application, because it's not our core business and I've spent too much time trying to get our code to do all the things I need. Time for a specialist, I think. My requirements, in decreasing order of importance, are below. Does anyone have experience with any commercial or free libraries that meet most or all of these requirements?
Has to work in Windows XP and higher. (But not Win95/98/Me.)
Visual C++ 2005 compatible, where screenshot can be triggered from my code. Preferably a static library, but a DLL or COM object is OK. I'd prefer not to shell out to a standalone EXE because there are some users that will try to tamper with our application and I think having an obvious separate screenshot EXE makes that too easy.
Must be able to take full screenshots of multiple monitor systems. (Preferably the way the "Print Screen" key does in Windows, by making a bitmap of the displays stitched together, but if I have to take the pictures separately and combine them myself that's acceptable.)
Must be able to capture screen correctly when Remote Desktop Client (or any RDP client or VM) is in full screen mode. (Of course, it should also work when RDP is in windowed mode, but that shouldn't be a problem as long as it doesn't operate by simulating a key press that might get transmitted to the remote OS instead of being handled locally.)
Must be able to capture screen correctly when Windows Media Player (or any other media player) is in full screen mode.
Must be able to capture screen correctly when game (e.g. World of Warcraft) is in full screen mode.
Would be nice to be able to capture a few seconds of user activity as a video.
I don't know of a library that would do what you want.
If I had to code your requirements, I would probably use the source code of the TightVNC server as my starting point. I think it has the technology to do everything on your list EXCEPT....
I'm not sure that technically there's ANYTHING that can do a screen capture of somebody's Remote Desktop session. Think about it: There can be multiple remote desktop sessions (the csrss.exe process) occuring using the same physical remote desktop server. If you were sitting in front of the machine looking at the video monitor, you wouldn't see anything happening at all. So what woould you expect to capture. VNC is only going to capture what's happening with the "real" video (the non-remote csrss.exe).
I dont know if this really helps, but the best imaging libraries available are available from
www.accusoft.com and
www.leadtools.com
Both support creatting screenshots, though i don't know, if hey will properly capture movie player output that displays through graphics acceleration or the recording of movies from screen.
If I were you I would investigate WindowsClippings, a pretty mature and extensible application written in C++ that does precisely what you need. It has an API you can extend to your requirements and is pretty cheap at 18$
Some people in our office are using Magick++ (an ImageMagick library) to make screenshots. I don't know all the specs, but you could take a look at it and see if it matches your requirements.
I'm using WinDBG occasionally to analyze problems in production environment, where VS cannot be installed. There's no doubt it's an extremely powerful tool, but using it is a bit annoying. Even though the product is frequently updated, its GUI goes back to the Win95 days or so, and its usability is accordingly. Having to fight the GUI to layout the windows the way I want, and having to remember all those textual commands, is just quite low a standard for a modern desktop application.
AFAIK, WinDBG is pretty much built on top of CDB, which is a command line debugger. Being so, it shouldn't be that hard to built a modern days GUI wrapper that will replace the existing dinosaur. Has anyone ever done that? Am I the only one having those mixed feelings toward WinDBG?
(BTW, I know I can create a dump and take it back to where I have VS, but I sometimes have to debug 64 bit processes, and I don't have a 64 bit dev machine. Sad, but true)
Consider the new WinDbg. (It's still in Preview). It also supports Time Travel Debugging.
You can install it from the Microsoft Store, or use the links here.
Here is what's new with Windbg Preview.
Have look at this if you fancy trying out a GUI to replace WinDbg.
EDIT:
Since SOS Assist is no longer available, this answer should be deleted. As this answer has been accepted, I personally cannot delete it. In that, please ignore my answer.
I guess thats too much to expect. With such a large number of commands that it has, it will not be trivial to have UI that displays everything in fancy controls. It might also make it bulkier, slower.
However it does provide you with controls that any user mode application debugger should have. It displays most frequently needed information like call stack, local variables, threads and so on in seperate windows.
But if you need more advanced debugging feature, you alwalys have the command interface.
WinDBG is pretty much it, no one has ever bothered to write their own UI for it. Even with its quirks I'm a fan because it's mostly command line driven. So, to each their own :)
Note that the VS 2011 Dev Preview basically integrates WinDBG support, so in the future VS will be the new WinDBG UI.
-scott
Given that I only have one monitor, what's the best way to debug a program which uses the entire screen (such as a DirectX application)? Tools such as the step-by-step debugger seem useless in this context. Also, printing to the console isn't as effective, since you can only look at the console once the application has terminated.
Remote debugging is no option?
Else you can possibly borrow a second monitor (with video card).
And if all else fails you can go back to beep signals.
(Or find yourself an old matrix printer and write each line to the printer ;-) )
To just see some runtime information I would overlay debug text within fullscreen. If it were me, I would target the app to be able to run windowed as well- although the onscreen debug is good for play testing (if this is a game).
printf debugging is slow, painful and fool proof.
fill your code full of tracing lines like
fprint(logfile,"%s:%d\n",__FILE__,__LINE__);
or waterer you need for your language and run it. after your done, you can walk through what it did. Make sure you have lots of time and harddrive space first though. It has some advantage like that you can "run" things backwards and diff one run with the next.
I'll go with what BCS said and add that DebugView by SysInternals allows you to connect to it remotely from another machine.
You can test 99% of the code in windowed mode, then for the parts that need to be done in fullscreen you can have it jump to fullscreen, run some test, and jump back soon after (either programmatically or with alt-tab).
Basically I want to stress that most code will not be dependent on the fullscreenness and could be tested in a small window.
You might want to consider reading Joseph Newcombers essay on Graphical Developers Interfaces at http://www.flounder.com/gdi.htm
You may not be coding in MFC but you should be able to get some useful ideas. He's got lots of other interesting articles as well.
Has anyone noticed this odd behavior of application that utilize D3D or OpenGL when they go to full screen in Windows? It applies only when applications go to full screen and then switch back to window or terminate. They either shuffle window positions of other applications (when I am on single monitor machine), or move all the other applications windows to another screen when I am on multiple monitor machine.
I would take this for granted if there weren't for applications that didn't show this two anomalies. So, my question would be what exactly does one need to take care of when writing an application to alleviate these two problems? Also, I am not sure if this problem exists on other platforms besides Windows?
My primary setup concerning this is OpenGL/C++, but I presume this applies to whatever setup you have since it seems to be platform API thing that needs to be taken care of.
edit: OK, here is some more clarification on my observation. Problem persists even on same resolution as desktop one. So, it does not seem to be related to resolution switch, because I've seen application/games that even when they are not in the same resolution as desktop, when they switch back, windows on desktop are restored as they once were before the full screen application was run.
edit2: it looks like it is a resolution switch problem, Windows (at least XP) does not seem to remember positions and size (in case of multiple monitor setup) of applications windows. Looks like only solution is the one I provided in an answer to the question - even though it seems like something OS should provide, at least as an API call or two. I'm still not convinced this is the only solution, there must be an easy way of graceful, easy restoration, no?
Shouldn't you be using ChangedDisplaySettingsEx(..., CDS_FULLSCREEN, NULL)? That will tell the system the resolution swap is temporary.
I can't say that I'm 100% certain about the situation you're experiencing. However, my guess is it's because most D3D/OpenGL games will change the resolution of your machine when they startup/shutdown for performance reasons.
The ones you see that don't shuffle the windows around are likely not changing the resolution because they may be able to run at your current settings.
Hm, I've gone through some more research about this - it looks like there is no default fallback on restoring all running windows sizes and positions after changing resolution, so it must be done from within an application (at least in XP).
So, in order to gracefully return back from other resolution (full screen game for example), I would need to get all running applications hWnd's with EnumWindows and appropriate callback and store each of the windows RECT structure via GetWindowRect in a list.
When switching back to desktop resolution I would EnumWindows again, but with a different callback which sets each of the running application windows position and size with SetWindowPos, using the list of RECTs I've saved before switching to full screen.
There are gotcha's, ofcourse, like watching you get a window hwnd only through EnumWindows etc. It seems odd that OS doesn't provide a feature like that, even if only API. I wonder how other OS's out there handle this, if they handle it at all.