Mr N

I haven’t even got my own copy of Windows 7 yet. The I.T. department is rolling it out across the company and already my colleagues are complaining about its idiosyncrasies. Phrases like “What the hell is that green bar doing again?", “it keeps doing a different thing each time” and “there so much GUI I can’t actually see *my* stuff". So I have started this article as blogglue to join together all the blogs, articles and links I will discover or write that tell you how to switch off or work around all the new “features” of Windows 7. God help us all - I am more seriously thinking of switching over to MacOS than ever before. Think I might start with a laptop (they are kind of sexy) and after all it is Unix underneath (queue coy smile). A lot of these “features” exist in Windows Vista as well and may work there too. Anyway here’s one I know I will need because it has made its way from Vista which is on one of my home computers :( Remove Favorites, Libraries, and Homegroup from Navigation Pane This is a real pane (get it?). Favorites and Libraries occupy quite a large proportion of the navigation panel in File Explorer. This means that when ever you load it in you always have to scroll down to the place you want. You can rarely get the whole thing in one panel without scrollbars. As soon as the scrollbars appear you need to make the panel wider because the ends of the folders are now hidden behind the scrollbars and the thing keeps shifting from left to right whenever you move around. http://social.technet.microsoft.com/Forums/en/w7itproui/thread/ac419c2b-4a38-44f0-b1f0-b0ed9fdcfdeb Where is Quick Launch on Windows 7 http://www.howtogeek.com/howto/windows-7/add-the-quick-launch-bar-to-the-taskbar-in-windows-7/ Automatically Expand Navigation Pane Tree to Current Folder in Windows 7 I’ve been trying to use the new Windows Explorer style of navigating around the directory structure but it makes it really difficult to compare directories. The biggest pain is that if you cut and paste a directory into the navigation bar at the top then the directory tree structure doesn’t expand out to display where you are in the file system. If you are comparing folders or have folders that are similar then you never know which one you are looking at. You also can’t hop between different folders in a random-access way, you either have to go forwards/backwards or think about where those folders live to expand them. I spent most of my explorer time synchronising the tree view with the file view. http://www.mydigitallife.info/automatically-expand-navigation-pane-tree-to-current-folder-in-windows-7/ How To Toggle the Navigation Pane with a Button in Windows Explorer http://mintywhite.com/windows-7/7customization/toggle-navigation-pane-button-windows-explorer/ Update your SendTo list Start -> Run, enter shell:sendto to open the SendTo folder; then just drag the applications you want into it. http://gigaom.com/mobile/customize-the-windows-7-send-to-menu-option/ Windows removes context menu entries when more than 15 files are selected Strange one this! To stop us doing stupid things when large numbers of files are selected, Windows removes most of the “add-on” entries from the context menu. Nice idea in principle, but if you’re trying to add a load of source files to a source controller then you can’t. http://www.ghacks.net/2011/03/05/fix-context-menu-items-missing-in-windows-explorer/ Folder view is different even, though you have set them to be the same Under Windows XP you would configure a folder just the way you like it and then go to Tools->Folder Options…, select the View tab then click the Apply to Folders button. From that point on your lovely settings would be used across all folders. This is not the same under Windows 7. If you read the Folder views title it says viewS and the blurb says “You can apply the view (such as Details or Icon) that you are using for this folder to all folders of this type“. Windows 7 decides what class of folder it is and lets you create a viewing profile for how to view the contents of that folder. We are not sure how it decides, probably Microsoft Voodoo, or how you can find out what classes of folder you have. The up shot of this, is that if you have a all folders of pictures will show thumbnails and all folders of Word documents to show full details. To make this work you must go to a folder and set it up the way you want and click through to the Apply to Folders button. You’ll have to do this for each of the folder classes individually. Windows Explorer expands folders inappropriately, jumping the folder you expand to the bottom of the navigation pane This is by far and away the most annoying bug I’ve found in Windows 7 so far. If you use the left hand directory tree to navigate your way around the filing system then you will definitely have noticed this bug. As you expand each of the tree branches the branch you have just expanded jumps to the bottom of the screen. So to navigate down a directory you have to expand, scroll the newly expanded directory back to the mouse pointer, expand the next folder down, scroll the newly expanded directory back to the mouse pointer. If you keep the folder at the bottom where it has moved itself you still have to scroll upwards because you can’t see the next folder to expand. Just to show how much Microsoft listens to its customers there are 23 pages of requests to fix this on the Microsoft answers site spanning 2 years, with no official answer. There is also an issue on Microsoft’s Connect site with a hundred people asking for this issue to be addressed. There is however a list of work-a-rounds, one of which is to install ClassicShell which is a SourceForge project that, amongst other things fixes explorer and replaces the crappy new start menu with the old style one. Give it a go! Resources If you can’t find what you are looking for here, then try these pages: http://blogs.msdn.com/b/tims/archive/2009/01/12/the-bumper-list-of-windows-7-secrets.aspx

With all projects we must create an area to place our sources so that we both have a frame of reference.

mkdir c:\python-modules

Next we must download the sources we need. First up is Python itself. Navigate to: http://www.python.org/download/ Download the bzipped source tarball and uncompress it into c:\python-modules\Python-2.7.1 using 7-zip. Next up we are going to download the pre-compiled OpenSSL development libraries (containing the headers, DLLs and libs) for the win32 and x64 platforms. So navigate to: http://code.google.com/p/openssl-for-windows/ Click Downloads at the top of the page and download the latest _WIN32 and _X64 which in my case is openssl-0.9.8k_WIN32.zip and openssl-0.9.8k_X64.zip. Unzip them to C:\python-modules\openssl-0.9.8k_WIN32 and C:\python-modules\openssl-0.9.8k_X64 respectively. The Python project has a funny directory structure so we need to merge the OpenSSL folders to keep it happy. Create a new folder just containing the openssl-ver i.e. without the platform name. Which in my case would be:

mkdir C:\python-modules\openssl-0.9.8k

Now we must copy the lib and include folders from the platform specific folders into the combined folder as a different name which incorporates the platform number. Windows batch copying commands are a joke (you seem to have to know in advance what the directory structure looks like before you can copy files into it) but here you go:

cd C:\python-modules set OPENSSL_DIR=openssl-0.9.8k mkdir %OPENSSL_DIR%\inc32\openssl mkdir %OPENSSL_DIR%\inc64\openssl mkdir %OPENSSL_DIR%\out32 mkdir %OPENSSL_DIR%\out64 xcopy /e %OPENSSL_DIR%_WIN32\include %OPENSSL_DIR%\inc32 xcopy /e %OPENSSL_DIR%_X64\include %OPENSSL_DIR%\inc64 xcopy /e %OPENSSL_DIR%_WIN32\lib %OPENSSL_DIR%\out32 xcopy /e %OPENSSL_DIR%_X64\lib %OPENSSL_DIR%\out64

Copying under Windows is so good, it’s easier to use explorer! Unless there isn’t anyone there because you’re running in a batch file. I digress. Now that we have the directory structure that the Python builder desires we must change the Visual Studio project properties file to update the opensslDir property. The creator of the project files was using openssl-0.9.8l which wasn’t available in a pre-built binary for both our platforms. Load C:\python-modules\Python-2.7.1-win32\PCbuild\pyproject.vsprops into your favourite text editor and change the macro opensslDir to be the same name as your OpenSSL directory. The Python Visual Studio solution tries to build OpenSSL from sources which is a bit bizarre so it has to use a combination of ms-dos batch files, python scripts and perl scripts in order to determine how to build OpenSSL. This creates a dependency on you having pre-installed python and pre-installed Perl. Why give yourself more work? OpenSSL comes in pre-built releases for win32/x64. Now that we have got the ssl folders in the right places we can get rid of the build_ssl.py pre-build option that requires Perl to be installed. I really do wonder what the project architects where thinking when they set it up this way. “Let’s double the amount of work we must make everyone do by forcing them to build all the dependencies from source". “Ace and while we’re at it let’s add loads of dependencies so they have to install all kinds of extra stuff they are never going to use for anything else” ….what really?????? NO, No, No let’s use the other project’s pre-built development libraries so we can just compile against their stable versions. Sorry feeling a bit ranty today. Now that we have re-organised the OpenSSL to use pre-compiled libraries we can remove all the dependencies in the Visual Studio solution that try and use Perl and build OpenSSL from source. Change to the C:\python-modules\Python-2.7.1\PCbuild directory and load _hashlib.vcproj and _ssl.vcproj into your favourite text editor. Remove all the VCPreBuildEventTool configuration Tool commands which refer to build_ssl.py for all configurations (Win32|Debug etc). In true windows fashion, you must shutdown Visual Studio and restart it by running the pcbuild.sln. This will pick up the new settings from the updated property files. Set the Solution Configuration to Debug or Release and set the Solution Platform to Win32 or x64 for the desired build. From the menu select Build->Build Solution. I selected win32 debug and ran the build. The build process creates all the intermediate files in Python-2.7.1\PCbuild\Win32-temp-Debug and placed all end product files into Python-2.7.1\PCbuild. I needed to build all the combinations of releases for our in house development and production releases on each of our supported platforms. So I need to run the build 4 times with Win32/Debug, Win32/Release, x64/Debug and x64/Release. After each build I need to copy the output files out of the PCBuild folder into somewhere else. The win32 platform build, places intermediary build files into PCbuild/Win32-temp-[Debug|Release]/<proj> whereas x64 places everything on one level at PCBuild/amd64, presumably because their definitions where created by different people. Each build type however saves the deliverables into the same location, presumerably because this is where the installer creator picks them up from. In order to build our product we need the python27.dll, python27.lib and python27.pdb for the Release versions and python27_d.dll, python27_d.lib and python27_d.pdb for the Debug versions for both win32 and x64. The easiest way to find them is by right-clicking on PCBuild selecting Search and entering

python*.dll;python*.lib;python*.pdb

then you don’t need to hunt around for them :( Between each build make sure you do a Build->Clean Solution to clean up any artefacts that may interfere with the build. Well that’s 2 days I’ll never get back. Windows programmers should *really* take a leaf out of the Unix programmers book.

A while ago I wrote a blog article about Searching file contents under Windows XP. I was wondering why my searches of Visual Studio Project files with the extensions .vsproj, .vsprops and .sln files were coming back with no results. I read my previous article and noticed that it said “Index files with unknown extensions” and these files were known extensions. So this is another candidate for the Switching off Windows XP “features”. There is a Microsoft Knowledge base article about this but both the solutions are inadequate. According to them you have to set a PersistentHandler for each known file extension that you want to search. A bit of playing and I figured out that if you set the PersistentHandler of the extension “*” then it becomes the default searcher. So here is what you do:

1. From the start menu, select Run and type regedit
2. Navigate to: HKEY_CLASSES_ROOT\*
3. Right click on the “*” folder and select New->Key
4. When the folder appears set the name to PersistentHandler.
5. In the right hand pane edit the (Default) data to {5e941d80-bf96-11cd-b579-08002b30bfeb}
6. Click Ok

The GUID {5e941d80-bf96-11cd-b579-08002b30bfeb} points to the Plain Text persistent handler which in turn points to an InproServer32 which contains the query.dll.

Python 2.7 (final) was released on 3rd July 2010, which is almost half a year ago. One of the awful things about Python is that major releases are not compatible with each other. That is the extension modules compiled against Python 2.6 do not play nicely with the extension modules compiled against Python 2.7. The upshot of this, is that if you want to upgrade your version of Python you have to hunt around looking for extension modules compiled against your new version. In spite of Python 2.7 being 7 months old (1 year + 1 month if you count back to the release of Python 2.7 alpha 1), there isn’t as much extension module support as you’d expect; you still have to hunt and most of it is on unofficial websites i.e. not in the download pages of its project.

One such project is the CORBA implementation omniORB. It’s download pages only contain the Python 2.6 version. While I can use ./configure to build projects under unix with ease the building of omniORBpy under windows was much more troublesome. I can see why no one has attempted it thus far.

So for all you lucky people out there here is how you do it.

You need to have Python installed but you probably have that already so I’m not going to talk about that here.

We need to compile the omniORB library first then we can compile the omniORBpy against that.

Firstly we must create a directory to download our source software into:

mkdir C:\python-modules

Then download and unpack the source code. omniORB is housed at SourceForge so go to the download page at:

http://sourceforge.net/projects/omniorb/files/

and download the latest omniORB (omniORB-4.1.5.tar.bz2) and omniORBpy (omniORBpy-3.5.tar.bz2) We also need the openssl implementation which can be downloaded from:

http://code.google.com/p/openssl-for-windows/downloads/list

The latest one is openssl-0.9.8k_WIN32 (at the time of writing).

Unpack them all into C:\python-modules so that we have three folders C:\python-modules\omniORB-4.1.5, C:\python-modules\omniORBpy-3.5 and C:\python-modules\openssl-0.9.8k_WIN32.

omniORBpy-3.5 needs to be in a special place to move it to C:\python-modules\omniORB-4.1.5\src\lib\omniORBpy (removing the version number from the end of the directory name).

The build process needs Cygwin which I already had installed. I tried to use it in the build but it didn’t work, the “make” just hung. So I just stuck to the instructions and used omniORB’s cut-down version. You can download this from http://omniorb.sourceforge.net/att_packages/gnu-win32-lite.zip and unpack it into c:\gnuwin32.

Now that we have all the software downloaded, we can start configuring the build.

Edit C:\python-modules\omniORB-4.1.5\config\config.mk and uncomment the platform you are using in my case it is x86_win32_vs_9 Next load the platform specific file from C:\python-modules\omniORB-4.1.5\mk\platforms\x86_win32_vs_9.mk. As we will be building in a Cygwin environment, we need to specify paths in Cygwin format. Change the variable PYTHON to point to the correct location of the Python executable. In my case I have Python 2.7 installed (but anything above Python 1.5 is fine)

PYTHON = /cygdrive/c/Python27/python

OpenSSL transport support is disabled by default because you need the Open SSL libraries which we have now so uncomment the OPEN_SSL_ROOT location. The path has to be a relative path. I tried all combinations of windows-style full paths and cygwin-style full paths and none of them worked. “make clean” doesn’t reset the build like it should do :( So if there is a problem during the build you have to unpack the sources from the zips again to create a fresh source tree. Set the ssl root to:

OPEN_SSL_ROOT = ../../../../../../openssl-0.9.8k_WIN32

which is a relative reference to C:\python-modules\openssl-0.9.8k_WIN32 from C:\python-modules\omniORB-4.1.5\src\lib\omniORB\orbcore\ssl !

Now that we are configured we can actually start the build.

Open a command window and add c:\gnuwin32 to the start of your path:

set PATH=c:\gnuwin32\bin;%PATH%

Run the visual studio batch file to set up the build environment:

“C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat”

Not quite sure what this does but you need it. I think it has something to do with translating cygwin paths to windows paths

C:\gnuwin32\bin\checkmounts C:\gnuwin32

Change to the omniORB source directory and run the build:

cd C:\python-modules\omniORB-4.1.5\src make export

The build of omniORB will take about 30 minutes.

Next up is to compile the omniORBpy. Change to the omniORBpy source directory and run the build from there:

cd C:\python-modules\omniORB-4.1.5\src\lib\omniORBpy make export

The build of omniORBpy will take about 3 minutes.

Once the build has finished you need to create a module extension package so that you can give it to other people so they don’t have to go through all the hassle of downloading and compiling it all up.

The pre-built omniORBpy using Python 2.6 resident on SourceForge has a problem which means you need to adjust your PYTHONPATH and your actual PATH in order to use it. I use Clearcase which has everything on different drives so having to hard code drive letters made it almost impossible to use in a shared environment. Fear not I have done the 2 hours of reading really boring documentation so you don’t have to and constructed a omniORBpy 3.5 (omniORB 4.1.5) with Python 2.7 module extension that doesn’t require you to update your PATH or PYTHONPATH by making use of the site pth features and the nugget of information I found buried on a forum that said that a pyd (Python dynamic library) would pick up DLLs from the same directory it lived in automatically.

Unfortunately the build system is not set up enough so that you can make an installable deliverable to give out like you get with some projects (for example lxml). This means you have to do it by hand and it’s a real pain in the arse!

I’ve written a program to make the omniORBpy extension placing everything in the right place. It’s a bit rough but it works. You can download it from here:

omniorbpy-make-dist.py.zip

Well, thanks for reading all the way to the end (if you did!) and your prize is omniORBpy 3.5 with omniORB 4.1.5 binding using Python 2.7.1. Enjoy.

*Installation instructions*

1. Download omniorbpy-3.5.win32-py2.7.zip
2. Unpack omniORBpy-3.5.win32-py2.7.zip into C:\Python27\Lib\site-packages

Been doing a lot of Python programming recently and have found that I keep writing the same kinds of utilities. I thought I’d define them all here in functions so that I could cut and paste them as and when I need them. If you’re lucky I’ll write a little explanation (or tutorial) of how they work for the novice Pythoners out there. Display sorted environment

import os
def printenv():
  s = sorted(os.environ.items())
  for e in s:
    print "%s=%s" % e

os.environ is a map (collection of key/value pairs) so items turns it into a list of tuples so that it can be iterated over in a for loop. Each tuple contains the key and value of the map entry. The body of the for loop could also be written:

map_key = s[0]
map_value = s[1]
print "%s=%s" % (map_key, map_value)

or

map_key, map_value = s
print "%s=%s" % (map_key, map_value)

but you would only be adding extra stages.