add 'L' to hex constants to prevent negative values.
Patch is against stable version 0.5.9.

Logged In: YES 
user_id=6405

Will that value work OK when passed to the win32 C extension? 
 

Logged In: YES 
user_id=9205

Marking long hex values explicitely as a long with 'L' is a
core language feature. It is described in the Python
documentation here:
http://www.python.org/doc/current/ref/integers.html

So even without testing (I have no Windows available here ;)
I would say yes, this patch will work with win32 extension
installed.
And the same type of patch was applied to nearly all Python
modules using long hex values, for example in the msgfmt.py
tool.

Logged In: YES 
user_id=6405

I'm fully aware of what L does to an integer literal :) 
 
I'm concerned that the C extension code we're passing the value to 
won't like being passed a long integer. I have no way of testing that 
though. 
 

Logged In: NO 

I tested the patch today on win2000 and it does not work,
giving overflowerror exceptions. Hm, so my fix is obviously
wrong, you can close this patch as invalid, and I do not
want to dive into windows 32-bit integer math.
Anyway, for the .deb package I will just delete the
windows-specific stuff to avoid the FutureWarning :)

ciao, Bastian

Logged In: YES 
user_id=6405

I have a patch in 0.6 that does this: 
 
  FFFF0000 = 0xffff000 << 4 
 
and then uses FFFF0000 in place of 0xffff0000 - I believe this is a valid 
fix. 
 

Logged In: YES 
user_id=9205

the shift op still prints a warning:
>>> 0xffff000 << 4
/home/calvin/.python:1: FutureWarning: x<<y losing bits or
changing sign will return a long in Python 2.4 and up
  from __future__ import nested_scopes
-65536

Writing explicitely the above negative value in
portalocker.py does not print the warning, and seems to work
(I executed "python2.3.exe portalocker.py" for test).

Logged In: YES 
user_id=6405

OK, -65536 might be right - did you run the script once or twice 
(simultaneously) to make sure that the locking was actually working? 
 

Logged In: YES 
user_id=9205

Yes, I tested with this test.bat:
start c:\Python23\python.exe portallocker.py
start c:\Python23\python.exe portallocker.py

The second call blocked ok until the first lock was released.
Platform: windows 2000 sp4, python 2.3, win32 extensions v155.

Logged In: YES 
user_id=6405

Thanks so much for following up on this! 
 
Don't suppose I could convince you to poke around the roundup-server 
script and fix the win32 server mode? :)