Process ID reuse on Windows

Process IDs are reused on Windows after uptime has been long enough. Probably for compatibility with old applications, Windows tries to use 15 bits process ids for as long as it can and they eventually grow to 31 bits values if you create enough processes simultaneously.

I always though process ids weren't reused until it was unreferenced. I was wrong in how it is referenced. I thought that having a process ID as a parent of another live process was enough but I was wrong, it needs to have a handle alive.

Here's an example screenshot. This kind of behavior can be recreated by having a lot of orphan processes that no process keeps an handle to their parent:

I found this behavior while recreating a process tree tool. Naively checking the process ids is not sufficient. As you can see, Process Explorer already know about that fact and doesn't simply compare the process IDs. It uses another comparison else to discover the real parenthood. PROCESSENTRY32.th32ParentProcessID doesn't give enough data to discriminate. So the only good way is to use GetProcessTimes() and verify the process creation dates.

usb key windows install

These days I install Windows 7 often but I can't help to remember the steps from Vista:

Open an elevated command prompt:

diskpart
list disk
select disk 2   <- choose usb key!
clean
create partition primary
select partition 1
active
format fs=fat32 quick
assign
exit
xcopy /h /e /q path\to\uncompressed\iso e:\   <- choose usb key!

All this can be done through GUI with Computer Management / Disk Management. Choose an open source program in http://en.wikipedia.org/wiki/List_of_ISO_image_software for the iso extraction.

Section synchronization

I was looking at a cleaver way to use interprocess communication and we (chromium) use shared memory with CreateFileMapping(). The main issue is synchronization. I was looking at using the section as an inherent synchronization tool but it fails miserably. I finally found the answer: « File mapping objects do not support the SYNCHRONIZE standard access right. »[1]

That would have been useful, even if it would have been limited to 4kb granularity or even just a global section lock. Sad. Going back to mutex. :(

[1]

http://msdn.microsoft.com/en-us/library/aa366559.aspx

EMF buffer idiocracy

On Windows XP, when creating an HDC from an EMF buffer with CreateEnhMetaFile():

• SetDCBrushColor() and SetDCPenColor() calls are not recorded. Too bad for you.
• When using GetStockObject(), DC_BRUSH and DC_PEN are useless and will return a white pen and a black pen respectively. Just don't use them.
  
• Expect no-op from ExtTextOut(..., ETO_GLYPH_INDEX, ...) if GDI32!GdiInitializeLanguagePack hasn't been called.