Removed considerations for Windows 95/98/ME #2400
Conversation
Avasam
force-pushed
the
Remove-Windows-95-98-ME
branch
from
c06e77c to
2935175
Compare
| // Global\\ etc goodness: | ||
| // On NT4/9x, 'Global\\' is not understood and will fail. | ||
| // On 2k/XP, anyone can create 'global' objects. | ||
| // On Vista, you need elavated perms to create global objects - however, once | ||
| // On Vista, you need elevated perms to create global objects - however, once | ||
| // it has been created and permissions adjusted, a user with normal | ||
| // permissions can open these global objects. |
| // Do a LoadLibrary, as the Ex version may not always exist on Win95. | ||
| // TODO: We no longer support Windows 95, how should this code be updated ? |
There was a problem hiding this comment.
We no longer support Windows 95, how should this code be updated ?
There was a problem hiding this comment.
I think the comment can just be removed - there's no LoadLibrary done here at all, right? But if there was, the comment is implying we could now use LoadLibraryEx if there was a good reason to do so.
| # in order to *use* the username/password of a particular dun entry, | ||
| # one must explicitly get those params under Win95 ... | ||
| # TODO: We no longer support Windows 95, how should this code be updated ? |
There was a problem hiding this comment.
We no longer support Windows 95, how should this code be updated ?
| | win32con.MIIM_TYPE | ||
| ) | ||
| # Note: No MIIM_TYPE - this screws win2k/98. |
There was a problem hiding this comment.
This needs to be tested, I have no idea of its actual effect. Just following the comment.
There was a problem hiding this comment.
wouldn't it be safer to not add this constant, but leave a comment which notes it wasn't added due to those old windows?
| // On platforms that don't have NT security, | ||
| // the initialization of the SECURITY_DESCRIPTOR should fail, | ||
| // leaving the sd NULL. |
…e-Windows-95-98-ME
| // Do a LoadLibrary, as the Ex version may not always exist on Win95. | ||
| // TODO: We no longer support Windows 95, how should this code be updated ? |
There was a problem hiding this comment.
I think the comment can just be removed - there's no LoadLibrary done here at all, right? But if there was, the comment is implying we could now use LoadLibraryEx if there was a good reason to do so.
| | win32con.MIIM_TYPE | ||
| ) | ||
| # Note: No MIIM_TYPE - this screws win2k/98. |
There was a problem hiding this comment.
wouldn't it be safer to not add this constant, but leave a comment which notes it wasn't added due to those old windows?
| @@ -467,7 +467,7 @@ def RegisterShellInfo(searchPaths): | |||
| core path, you can avoid packages re-registering the same path. | |||
| -m filename -- Find and register the specific file name as a module. | |||
| Do not include a path on the filename! | |||
| --shell -- Register everything with the Win95/NT shell. | |||
| --shell -- Register everything with the NT shell. | |||
There was a problem hiding this comment.
This should probably just say "Windows shell"?
| return PyErr_Format(PyExc_RuntimeError, "This version of Windows does not support this function"); | ||
| } | ||
| PFNGetClipboardSequenceNumber pfnGetClipboardSequenceNumber = | ||
| (PFNGetClipboardSequenceNumber)GetProcAddress(hmod, "GetClipboardSequenceNumber"); |
There was a problem hiding this comment.
A null check still makes sense to me
Please review this carefully, I'm a bit out of my depth in certain places and am left guessing. I've left GitHub comments on specific files.