Windows 7 Devices and Printers window doesn’t load

From some point, Devices and Printers window of my Window 7 64-bit doesn’t show anything, with the green bar going on forever. It turned out that this is because I stopped Bluetooth Support Service of my box to secure a bit of memory. I had to enable it back and everything works as expected.

Reference: http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/1584cd60-b06b-4550-a5dd-62eea5754947/

Windows 7 Devices and Printers window doesn’t load

Some Python subprocess.Popen tips

subprocess.Popen non-blocking pipe I/O using an additional thread and an asynchronous queue:
http://stackoverflow.com/questions/3076542/how-can-i-read-all-availably-data-from-subprocess-popen-stdout-non-blocking/3078292#3078292

Why subprocess.Popen fails on Windows with a command having a Unicode filename within it: it internally uses CreateProcessA, which is the single-byte character version of CreateProcess, meaning that it won’t handle Unicode characters correctly. For this to be correctly handled, the command line, and hence the filename contained, needs to be encoded with the file system encoding, that is usually MBCS.
http://stackoverflow.com/questions/1910275/unicode-filenames-on-windows-with-python-subprocess-popen/9113914#9113914
This thread and the pep below describe exactly this problem as well as the workaround above mentioned.
http://stackoverflow.com/questions/2595448/unicode-filename-to-python-subprocess-call/11442604#11442604
http://www.python.org/dev/peps/pep-0277/

You will need to specify the encoding of the Python file if you use Unicode characters there: most simply add # encoding=utf-8 as the first or the second line of your source code although there are some more degrees of freedom, which can be found here.
http://www.python.org/dev/peps/pep-0263/

Some Python subprocess.Popen tips

CreateWindow/CreateWindowEx Win32 function behaviors on Windows 7/Visual Studio 2012 differently from Windows 7/Visual Studio 2010.

This happened to me when I migrated my Visual Studio 2010 project files to Visual Studio 2012. The same code didn’t work in the same way it used to work with Visual Studio 2010. I found that if I change the tool set to v110 (Visual Studio 2010), the code works ok. I also found, however, that the target .NET framework is always 4.0 regardless the tool set version.

To my gut feeling, the new Visual Studio uses a different Windows SDK/.Net Framework which is targeted to Windows 8.

I tried to change the target framework by modifying the existing project files as well as creating new ones with .Net Framework 4.5 selected. I referred to this article, but could not find the tag instructed to modify. Instead I modified the following line, but it didn’t help.

<Project DefaultTargets=”Build” ToolsVersion=”4.5″ xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″&gt; …

When I tried to create a new project with .NET Framework 4.5, it didn’t really use 4.5, but 4.0 according to the property page. Maybe .NET Framework 4.5 is not installed in my machine, and Visual Studio 2012 should work with 4.5… Also refer to this article, which seems the most relevant to my problem and may help.

In conclusion, just fall back to the old 2010 tool chain (v100) to work around this problem.

Check hard drives in Windows

To check a hard drive, run this in the administrator shell:

chkdsk /f drive:

To schedule a multiple hard drive checkup (chkdsk /f) at boot, run this in the administrator shell:

fsutil dirty set drive:

for all drives you want to check.

http://technet.microsoft.com/en-us/library/cc730714(v=ws.10).aspx

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_dirty.mspx?mfr=true

Check hard drives in Windows

Notes on Multiple OpenGL windows using GLUT

Call glutCreateWindow for each window. Window size and position can be specified with glutWindowSize and glutWindowPosition prior to glutCreateWindow. Calling glutCreateWindow multiple times effectively creates multiple OpenGL contexts, meaning that you need to properly initialize each context after calling glutCreateWindow. In particular, take care of buffer objects and textures. Those created with a context cannot be used with other contexts.

OpenCL context created with an OpenGL context bound for the inter-operation can neither be used with other OpenGL context which are not bound to OpenCL context (need to be proven).

Notes on Multiple OpenGL windows using GLUT