Saved for later reference » win32

“Please provide path to Windows media (x86 processor)” when installing printer

Lars Erik Jordet — Mon, 17 Jan 2011 19:45:39 +0000

When installing a new printer earlier, I first installed it in Windows Server 2008 R2 (which of course only exists in a x64 version), and tried to add the x86 (XP) driver since all the clients run XP.

After providing the “additional drivers”-wizard with the printer driver, it asked me to “Please provide path to Windows media (x86 processor)”, which was a bit difficult since I had no 32-bit media (I would have tried 2008 32bit or similar, if so).

Turns out, the solution is blindingly simple: Share the printer, and with an admin user (typically the same who installed the printer on the server), log on to an XP computer, and install the shared printer from there. It will ask you to provide the driver since the server has none. After installing, go into printer properties in XP, find Sharing, Additional drivers…, and check off “Windows XP/2000, x86″. The driver will be uploaded to the server.

“Microsoft Dynamics CRM for Outlook with Offline Access has already been configured for a user on this computer. Only one use can be configured per computer for Microsoft CRM for Outlook with Offline Access.”

Lars Erik Jordet — Fri, 03 Sep 2010 11:46:57 +0000

If you try to swap users on a laptop, with Dynamics CRM installed in Offline Access mode, it will give the error above; searching gave me this page from the Chinese Dynamics CRM team, so I’m just going to repeat it here:

1
2
3
4

C:\>osql –E –S localhost\CRM
1> drop database mscrm_msde
2> go
1> quit

Basically, you connect to the SQL Server on the local computer, and delete the Offline Access database, allowing you to reconfigure as normal. Note that this won’t let you reconfigure the user as “online only” – the new configuration will automatically be Offline Access.

Secondly, this works even if the user is not Local Administrator on the computer.

Script to add a network printer automatically in Windows

Lars Erik Jordet — Tue, 24 Aug 2010 08:47:04 +0000

I recently had to replace a defective printer with a similar model, but different enough to need a new driver. This meant it would have a new name on the print server, and I had to figure out a way to replace the installed printer on each computer quickly. After some searching, I ended up with the following script:

1
2
3
4
5
6

@echo off
set OLDPRINTER="\\printserver\Xerox Phaser 8560N"
set NEWPRINTER="\\printserver\Xerox Phaser 8560DN PS"
rundll32 printui.dll,PrintUIEntry /q /dn /n%OLDPRINTER%
rundll32 printui.dll,PrintUIEntry /in /n%NEWPRINTER% /q
rundll32 printui.dll,PrintUIEntry /y /n%NEWPRINTER%

The first rundll32 line quietly (/q) deletes (/dn) the printer named (/n) %OLDPRINTER%, while the second line installs (/in) the new printer %NEWPRINTER%, and the final line sets the new printer as default (/y)

“Couldn’t generate the upgrade script.” for version C.0.8.40 of MS SQL Reporting Services

Lars Erik Jordet — Mon, 05 Jul 2010 08:51:42 +0000

The error message “Couldn’t generate the upgrade script” pops up during configuration of Reporting Services for MS SQL Server 2005, if you install reporting services after installing a service pack – in my case Reporting Services was installed as SP1, while the main SQL Server 2005 install was updated to SP3.

Reinstalling SQL Server 2005 SP3 fixed it.

Mercurial module for Python 2.6/Win32

Lars Erik Jordet — Tue, 15 Jun 2010 09:44:43 +0000

I’ve compiled Mercurial 1.5.4 for Python 2.6, following this guide, and uploaded it here, since I guess it’ll be useful for later:

mercurial-1.5.4.win32-py2.6.exe

I use it for Trac 0.12 in a multi-repository setting, so we can keep our old SVN repo while having some of the larger projects on Hg.

Making a Trac install work on Apache 2.2/Python 2.6/win32, 2010 edition

Lars Erik Jordet — Mon, 25 Jan 2010 11:14:25 +0000

About 10 months ago I wrote a short article on getting Trac to work on Python 2.6 and Windows. Recently I updated the install, and took a look at how the situation is now.

This guide assumes you have a working install of Trac on Python 2.5/mod_python/Apache2.2 already, as described in the Trac install guide, and that Python 2.6 is installed.

What needs to be done:

Install Python 2.6 and Trac for 2.6
Build a new version of mod_python
Optionally Replace Apache DLLs (mostly if you followed my previous guide)

Required software

You’ll need Visual C++ 2008 Express Edition or any retail version of VS 2008 if you want to build your own mod_python for 2.6 (I’ll provide a precompiled one in this post).

Preparing

Install Python 2.6 and Trac on 2.6 (using “ easy_install trac” is recommended)

You’ll probably also want to easy_install Pygments for source highlighting.

Building mod_python for 2.6

This guide to mod_python covers the creation and installation of a compatible version of the module.

At this point, you should be able to restart Apache and load up your “old” Trac on Python 2.6, but with the error message that “svn” support is not installed.

A pre-built version of this can be found here: mod_python-3.3.2-dev-20080819.win32-py2.6.exe

Python SVN bindings

My old guide had instructions on how to build these yourself, but after that article was made, “official” Python 2.6 bindings have been released.

Most recent version as of this writing is the SVN 1.6.6 version of the bindings.

Replacing Apache DLLs to make libsvn work

Note: Only use these instructions if you experience problems, and/or you’re running a self-built version of the Python SVN bindings already.

There’s a slight difference between libapr-1.dll as supplied with Apache 2.2 and the one we built together with libsvn, so the fix is to replace the one in your Apache2.2\bin folder with the one from your Python2.6\Lib\site-packages\libsvn folder (copy the libsvn_*.dlls from the same folder into the Apache2.2\bin folder if you still get problems).

Restarting Apache now should make Trac work fully, with Subversion support.

lxml for Python 2.6/win32

Lars Erik Jordet — Fri, 18 Dec 2009 12:03:35 +0000

A quick post today: Using these instructions, I’ve built a statically linked lxml 2.2.4 for Windows.

I used the following versions of the libraries:

1
2
3
4
5
6

STATIC_INCLUDE_DIRS = [
"..\\libxml2-2.7.6.win32\\include",
"..\\libxslt-1.1.26.win32\\include",
"..\\zlib-1.2.3.win32\\include",
"..\\iconv-1.9.2.win32\\include"
]

1
2
3
4
5
6

STATIC_LIBRARY_DIRS = [
"..\\libxml2-2.7.6.win32\\lib",
"..\\libxslt-1.1.26.win32\\lib",
"..\\zlib-1.2.3.win32\\lib",
"..\\iconv-1.9.2.win32\\lib"
]

Download it here: lxml-2.2.4.win32-py2.6

Simple Python ctypes Example – in Windows

Lars Erik Jordet — Sat, 25 Apr 2009 08:56:11 +0000

I found this blog post, Simple Python ctypes Example, on Reddit, and thought I’d see how different the procedure was for Windows.

What you’ll need:

Visual C# 2008 Express Edition (Visual Studio 2008 will also work – and is what I used, but will again base this on free downloads)
Python 2.5 or higher (I used Python 2.6.2)

Creating the DLL

Create a file dlltest.c with the following content:

1
2
3
4
5
6
7
8
9
10
11
12

#include

BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved)
{
return TRUE;
}

__declspec(dllexport) int
multiply(int num1, int num2)
{
return num1 * num2;
}

Start the Visual Studio 2008 Command Prompt from the Start Menu (this sets up the path for the compiler and other files, which makes things easier) and go to the directory you saved dlltest.c to.

Compile it with the following command:

cl -LD dlltest.c -Fetest.dll

Testing the DLL

As in the original Linux example, this DLL is easily tested using similar commands:

1
2
3
4

>>> from ctypes import *
>>> libtest = cdll.LoadLibrary('test.dll')
>>> print libtest.multiply(2, 2)
4

So, that is the simplest DLL possible, I’ll look at (same as the original blog post) applying it to more complex examples later.

Patched libgmail for unicode handling

Lars Erik Jordet — Tue, 07 Apr 2009 09:28:51 +0000

libgmail 0.1.11 has a bug with unicode handling, when the sender of an email has a name with one or more non-ASCII character in it.

I’ve applied the patch I described in the link above, adding the function:

1
2
3
4
5
6
7
8
9
10

def to_unicode(xstr):
   '''
   Forces string to unicode
   '''
   if type(xstr) == unicode:
   return xstr
   elif type(xstr) == str:
       return xstr.decode('utf-8')
   else:
       return xstr

And changed all calls to var.decode(‘utf-8′) to to_unicode(var).

libgmail-0.1.11p1.zip (source package)
libgmail-0.1.11p1.win32.exe (win32 installer)

Making a Trac install work on Apache 2.2/Python 2.6/win32

Lars Erik Jordet — Mon, 30 Mar 2009 11:52:40 +0000

I recently upgraded the systems to Python 2.6, and the worst part of that was getting Trac to work again.

This guide assumes you have a working install of Trac on Python 2.5/mod_python/Apache2.2 already, as described in the Trac install guide, and that Python 2.6 is installed.

What needs to be done:

Install Python 2.6 and Trac for 2.6
Build a new version of mod_python
Build a new version of libsvn
Replace Apache DLLs

Required software

You’ll need Visual C++ 2008 Express Edition or any retail version of VS 2008.

Preparing

Install Python 2.6 and Trac on 2.6 (using “ easy_install trac” is recommended)

You’ll probably also want to easy_install Pygments for source highlighting.

Building mod_python for 2.6

This guide to mod_python covers the creation and installation of a compatible version of the module.

At this point, you should be able to restart Apache and load up your “old” Trac on Python 2.6, but with the error message that “svn” support is not installed.

A pre-built version of this can be found here: mod_python-3.3.2-dev-20080819.win32-py2.6.exe

Building svn/libsvn for Python 2.6

Follow my previous guide to compile and install Python SVN bindings.

At this point, if you restart Apache, your Trac will most likely throw an exception about “_mod” being undefined.

Replacing Apache DLLs to make libsvn work

There’s a slight difference between libapr-1.dll as supplied with Apache 2.2 and the one we built together with libsvn, so the fix is to replace the one in your Apache2.2\bin folder with the one you built yourself, and copying all the libsvn*.dll files you built in the previous step to the same folder.

Restarting Apache now should make Trac work fully, with Subversion support.