What happens during a display mode change (resolution, depth) on an ordinary computer? (classical stationarys and laptops)

It might not be so trivial since video cards are so different, but one thing is common to all of them:

• The screen goes black (understandable since the signal is turned off)
• It takes many seconds for the signal to return with the new mode

and if it is under D3D or GL:

• The graphics device is lost and all VRAM objects must be reloaded, making the mode change take even longer

Can someone explain the underlying nature of this, and specifically why a display mode change is not a trivial reallocation of the backbuffer(s) and takes such a "long" time?

The only thing that actually changes are the settings of the so called RAMDAC (a Digital Analog Converter directly attached to the video RAM), well today with digital connections it's more like a RAMTX (a DVI/HDMI/DisplayPort Transmitter attached to the video RAM). DOS graphics programmer veterans probably remember the fights between the RAMDAC, the specification and the woes of one's own code.

It actually doesn't take seconds until the signal returns. This is a rather quick process, but most display devices take their time to synchronize with the new signal parameters. Actually with well written drivers the change happens almost immediately, between vertical blanks. A few years ago, where the displays were, errr, stupider and analogue, when changing the video mode settings, one could see the picture going berserk for a short moment, until the display resynchronized (maybe I should take a video of this, while I still own equipment capable of this).

Since what actually is going on is just a change of RAMDAC settings there's also not neccesary data lost as long as the basic parameters stays the same: Number of Bits per Pixel, number of components per pixel and pixel stride. And in fact OpenGL contexts usually don't loose their data with an video mode change. Of course visible framebuffer layouts change, but that happens also when moving the window around.

DirectX Graphics is a bit of different story, though. There is device exclusive access and whenever switching between Direct3D fullscreen mode and regular desktop mode all graphics objects are swapped, so that's the reason for DirectX Graphics being so laggy when switching from/to a game to the Windows desktop.

If the pixel data format changes it usually requires a full reinitialization of the visible framebuffer, but today GPUs are exceptionally good in maping heterogenous pixel formats into a target framebuffer, so no delays neccesary there, too.

What's the API call to display an Explorer window with a specified file selected? Exactly as happens when you click the "Find Target..." button in the Properties dialog of a .lnk shortcut? I know there is function (or an interface method) for that, but I forgot the name, and cannot find it again.

Note that I'm aware of explorer /select,<pathname> command line and not interested in using it instead of API call.

You need SHOpenFolderAndSelectItems. This question was early discussed here - Programmatically selecting file in explorer
Dont forget to call CoInitialize before first use of SHOpenFolderAndSelectItems

I want to understand what precisely is happening behind the scene when I spawn a new thread in .NET, something like here:

Thread t = new Thread(DoWork); //I am not interested in DoWork per se
t.Start();

1. What thread-related objects are created in CLR and Windows kernel?
2. Why are those objects needed?
3. How much managed/unmanaged memory (heap and stack) is allocated on x86, x64 Windows?

UPDATE
I am looking for such objects as managed thread object, which is I assume is t, but perhaps some other additional managed objects; kernel thread object, user thread environment block and alike.

Many thanks!

Win32 and Kernel memory allocated

I'm not exactly sure how the .NET part works, but if the runtime does decide to create a real thread with the OS, it would eventually call the Win32 API CreateThread in kernel32.dll, probably from mscorlib.ni.dll

By default, new threads get 1MB of virtual address for the stack, which is committed as needed. This can be controlled with the maxStackSize parameter. The main thread's stack size comes from a parameter in the executable file itself.

In the process's address space, a TEB (thread environment block) will be allocated (see also). Incidentally, the FS register on x86 points to this for things like thread local storage and structured exception handling (SEH). There are probably other things allocated by Win32 that are not documented.

In creating the Win32 thread, the Win32 server process (csrss.exe) is contacted. You can see that csrss has handles open to all Win32 processes and threads in Process Explorer for some kind of bookkeeping.

DLLs loaded in the process will be notified of the new thread and may allocate their own memory for tracking the thread.

The kernel will create an ETHREAD [layout] (derived from KTHREAD) object from kernel non-paged pool to track the thread's state. There will also be a kernel stack allocated (12k default for x86) which can be paged out (unless the thread is in a kernel mode wait state).

Why so many things need to allocate memory for a thread

Threads are the smallest preemptively scheduled unit that the OS provides and there is a lot of context connected to them. Many different components need to provide separate context for each thread because system services need to be able to deal with multiple threads doing different things all at the same time.

Some services require you to declare new threads to them explicitly but most are expected to work with new threads automatically. Sometimes this means allocating space right when the thread is started. As the thread engages other services, the amount of memory used to track the thread can increase as those services set up their own context for the thread.

How much memory is allocated

It's hard to say how much memory is allocated for a thread since it is spread across several address spaces and heaps. It will vary between Windows versions, installed components and what is loaded into the process currently.

The largest cost is generally accepted to be the 1MB of address space used by default for new threads, but even this limit can allow many hundreds to be used in a single process without running out of space.

If the design is using many more OS threads than the number of CPUs in the system, it should be reviewed. Work queues with a thread pool and lightweight threads with user mode scheduling with fibers or another library's implementation should be able to handle mulithreading without requiring an excessive number of OS threads, rendering the memory cost of the threads to be unimportant.

Quite simply, how does one determine whether or not tomcat is running in windows, using the command prompt? I am writing a batch script that must do this. This is the bash version:

RESULT=`netstat -na | grep $2 | awk '{print $7}' | wc -l`

Where $2 is the port. I am looking for something similar to that. Please, don't just tell me to get Cygwin, of necessity this script must be able to run on machines that only have tomcat; to tell me simply to get Cygwin is not a solution, it is a workaround that in my case won't work.

Thanks.

Using WMIC

@echo off
wmic process list brief | find /i "tomcat.exe"
set result=%ERRORLEVEL%
if "%result%"=="1" echo "not running"
if "%result%"=="0" echo "running"

note : /i is to make the find operation case-insensitive.

When anti-viruses run some application in a virtual environment called a "sandbox", how does this sandbox precisely work from the Windows kernel point of view?

Is it hard to write such a sandbox?

At a high level such sandboxes are kernel drivers which intercept calls to APIs, and modify the results those APIs return using hooking. How an entire sandboxing solution works under the hood though, could easily fill several books.

As for difficulty, it's probably one of the harder things you could ever possibly write. Not only do you have to provide hooks for most everything the operating system kernel provides, but you have to prevent the application from accessing the memory space of other processes, you have to have a way to save the state of the changes a program makes so that the program does not realize it's running under a sandbox. You have to do all of this in Kernel mode, which effectively limits you to using C, and forces you to deal with different kinds of memory, e.g. paged pool and nonpaged pool. Oh, and you have to do all of this very fast, so that the user feels it's worthwhile to run applications inside your sandbox. 50+% performance hits won't be tolerated by most users.

I understand the difference between the two so there's no need to go into that, but I'm just wondering what the reasoning is behind why Windows uses both CR and LF to indicate a line break. It seems like the Linux method (just using LF) makes a lot more sense, saves space, and is easier to parse.

From Raymond Chen's blog:

http://blogs.msdn.com/b/oldnewthing/archive/2004/03/18/91899.aspx

My product is a C++ library, which, on Windows, is distributed as a dll. It makes very little use of the c-runtime (basic iostream and that's it), so I'm sure that all recent versions of the CRT will be fine.

Since my client is supposed to build his application using my dll, I don't want to impose upon him any specific runtime version. I'd like my dll to bind to whatever runtime library version my client's app is using (and I can assume that he'll use dynamic linking for his CRT). After all, isn't that what dynamic linking is all about? Is that possible?

EDIT: linking the dll against the static runtime libs won't work either, because then the static runtime (from the dll) and the dynamic runtime (from the client's application) will be mixed, which is bad.

EDIT: What I'm mainly asking is how do I tell the runtime loader to link my dll against whatever CRT the application is linked with? Something with the manifest, perhaps? More generally, my question is how to build a nicely-behaving dll, that's to be used by clients building they're own applications?

EDIT: Thanks to the advice in the answers, I've transferred all references to std classes into inlined functions in my headers, and linked my dll with the static runtime libraries. It now seems to work even in applications linked with different CRT versions.

There's no real way to ensure your DLL works with multiple runtimes -- any of the types that change between them can lead to incompatibilities. For instance, the size of an object can change, or the location of members in them. There is very little room in C++ for this kind of thing.

The best thing you can do is statically link to the runtime and ensure the exported API is limited to types strictly under your control -- no passing std::string to a function, no stdlib types as members, and don't new in one DLL and delete in another. Don't mix inline and exported functions (including constructors/destructors) for the same object, because member order and padding might change between compilers. The pimpl idiom might help here.

I have some code that launches an external program, although is it possible to specify the working directory, as the external program is a console program:

Code:

private void button5_Click_2(object sender, EventArgs e)
    {
        System.Diagnostics.Process.Start(@"update\update.exe");
    }

Yes, it's possible, use ProcessStartInfo object to specify all the params you need and then just pass it to the Start method like that:

var psi = new ProcessStartInfo(@"update\update.exe");
psi.WorkingDirectory = @"C:\workingDirectory";
Process.Start(psi);

I'm looking for suggestions on technologies to design a windows UI that's powered by HTML. I've run across HTMLayout which seems pretty good if not perhaps a bit limited. Are there any other technologies that would provide a good platform for creating an application UI based on HTML?

You could use chromiumembedded. You get the power of Google's Chrome in your application.

Evernote used CEF (Chromium Embedded Framework) when they moved from C# back to C++.

Unlike HTMLayout, CEF has a permissive license, which allows usage in commercial applications without paying royalties. The drawback would be the huge binary size.

How can I change the entire console's background color? I've tried SetConsoleTextAttribute and it only changes the background color of new text.

I effectively want the entire console to turn red when a serious error arises.

Thanks to everyone who attempts to help.

Try something like:

    system("color c2");

Does anyone know how to assign a window region (SetWindowRgn or Control.Region in WinForms) without killing the theming in the non-client area?

For example, running the following generates a Windows 2000-style unthemed title bar, border, etc:

var form = new Form { Width=500, Height=500, BackColor = Color.Azure };
form.Text = "But soft, what light through yonder window breaks?";
var region = new Region (new Rectangle (Point.Empty, form.Size));
region.Exclude (new Rectangle (100, 100, 300, 300));
form.Region = region;
form.ShowDialog();

I'm guessing it's to do with this MSDN article which says:

As long as a window has a non-NULL region applied to it (SetWindowRgn), the UxTheme Manager assumes that this is a specialized window and the window will not use visual styles.

...hence UxThemes assumes it's a specialized window. Is there a way to tell the UxTheme Manager explicitly to theme a window?

The answer to your question is that you cannot.

But a workaround, to give you a transparent section in your form, would be to add the WS_EX_LAYERED extended window style to your form. Then you can tell the Window Manager that you want to use a chroma-color key to make part of your form transparent:

SetLayeredWindowAttributes(
      Form.Handle, //  __in  HWND hwnd,
      RGB(0, 255, 0), //green is the color key     __in  COLORREF crKey,
      255, //window is opaque otherwise  __in  BYTE bAlpha,
      LWA_COLORKEY //use color-key (rather than per-pixel alpha)  __in  DWORD dwFlags
);

Then you can put your "transparent" area as lime green:

Which then at runtime will be transparent:

---

Update: When i use layered window to have full transparency mouse events do trickle through to what's underneath. Notice the "flag" icon highlight:

See also

• Window Overview -> Window Features -> Layered Windows
• SetLayeredWindowAttributes Function
• Extended Window Styles
• Layered Windows

I'm injecting a DLL into some process, the DLL has a worker thread that is running a message loop.

I'd like to quit the thread properly i.e. post a quit message (PostThreadMessage) and wait for it (WaitForSingleObject).

Where can i wait for this thread to close? I can't do it on DLL_PROCESS_DETACH because by then all of the threads are closed or terminated and I don't know when the process is about to close.

My only thought was, Is there a way to intercept the main thread message loop and look for the WM_CLOSE\DESTROY msgs?

I'd love to hear any other ideas\solutions.

Edit:
Tried to hook the main thread using SetWindowsHookEx with WH_CALLWNDPROC but it didn't worked quite well, I managed to hook and receive the thread's messages. However, I didn't received WM_QUIT message only WM_DESTROY and WM_NCDESTROY and they are all were associated with windows.

Thanks,
Omer

If you need to perform some action on "About-To-Close" you need to hook the main thread using SetWindowsHookEx with WH_CALLWNDPROC and look for WM_CLOSE and take action/signal the thread to close.