[MERGE] Fast _walkdirs for win32
John Arbash Meinel
john at arbash-meinel.com
Thu Jul 17 21:25:04 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alexander Belchenko wrote:
| John Arbash Meinel пишет:
|> Alexander Belchenko wrote:
|>
|> |
|> | 2) But anyway it failed because linker cannot find Win32 API functions:
|> |
|>
...
|
| I mean you could write this:
|
| +cdef extern from "_walkdirs_win32.h":
| + struct _HANDLE:
| + pass
| + ctypedef _HANDLE *HANDLE
| + ctypedef unsigned long DWORD
| + ctypedef long long __int64
| + ctypedef unsigned short WCHAR
| + struct _FILETIME:
| + DWORD dwHighDateTime
| + DWORD dwLowDateTime
| + ctypedef _FILETIME FILETIME
| +
| + struct _WIN32_FIND_DATAW:
| + DWORD dwFileAttributes
| + FILETIME ftCreationTime
| + FILETIME ftLastAccessTime
| + FILETIME ftLastWriteTime
| + DWORD nFileSizeHigh
| + DWORD nFileSizeLow
| + # Some reserved stuff here
| + WCHAR cFileName[260] # MAX_PATH
| + WCHAR cAlternateFilename[14]
| +
| + # We have to use the typedef trick, otherwise pyrex uses:
| + # struct WIN32_FIND_DATAW
| + # which fails due to 'incomplete type'
| + ctypedef _WIN32_FIND_DATAW WIN32_FIND_DATAW
| +
| + HANDLE INVALID_HANDLE_VALUE
| + HANDLE FindFirstFileW(WCHAR *path, WIN32_FIND_DATAW *data)
| + int FindNextFileW(HANDLE search, WIN32_FIND_DATAW *data)
| + int FindClose(HANDLE search)
|
| According to Pyrex documentation "cdef extern from..." imply
| "cdef" keyword for all definitions in this block. But this is not big
deal.
| And please, don't call me nitpicking, I'm just boring.
Ah, I'll do so. It looks cleaner, which is nice to have. Come to think
of it, that was one of the confusions because you still have ctypedef,
but not cdef...
...
|> Do we strictly depend on win32utils?
|
| Yes. Although win32utils is lazy loaded in osutils, but actually
| directly used
| regardless of underlying platform. There is top-level code:
|
| if win32utils.winver == 'Windows 98':
| _win32_abspath = _win98_abspath
|
| Probably it's wrong usage and should be fixed somehow.
No, this is fine. I was just confused and thought win32utils was from
the pywin32 packaged, not part of the bzrlib code. So I'm happy to make
this change.
|
|> Also, do we get 'Windows NT' for stuff like Vista and beyond?
|
| If you look at the win32utils.pt then you'll see this:
|
...
| According to MSDN we already supported Windows Vista, although I don't
| have it to test.
It works here. :) As this is our code, we can always maintain it. Again,
I was thinking it was a 3rd-party tool.
|> | But of course such change is entirely for your taste.
|> |
|>
|> I'm happy to bring in small changes that allow supporting Win98. I
|> wasn't going to base the whole work around it.
|
| Explicit win98 support don't worth of any effort. But IMO proposed
| change is really small
| and should not cost much for future support. But you guys know better.
|
Yep, the change is small and easy to do. I'm happy to do so. Attached
should include the changes you need to compile and support Win98.
As for getting this into 1.6... At the moment we have only released
1.6b3, which isn't even rc1. So there is still a chance. I don't really
know what Martin's specific release strategy is.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkh/qp8ACgkQJdeBCYSNAAPtkACfb9WwWOVVVoMD5AwLfSjY/RRC
CMUAnjxE/35KTQbG3QmHfZDGKSPRYWPZ
=Rm0J
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: win32_find_files_cleanup.patch
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20080717/59a04674/attachment-0001.diff
More information about the bazaar
mailing list