Start Me Up

According to the documentation the "Length"-field and the "MaximumLength"-field are values in bytes. This explains why the maximum path length with the "\\?\"-trick is a little bit over 32,000 characters (which is about 64 KB).

They can also be extracted without third party tools: open a command prompt (cmd.exe) drag and drop the kb...exe into the command prompt window add " -x" or " -c" (c with old updates, x with new updates) to add the command line parameter hit [enter]

The restriction you addressed in the FAT32 file system and the NTFS file system is probably the most difficult part to solve. Since these 2 file systems allow no object names (folder names or file names) longer than 256 characters, it will be a problem storing longer names if the file system driver prevents it. Your suggested solution to shorten long object names leads to truncated names and looses the uniqueness of the names. Once a name is shortened the truncated part is lost and we might have 2 folders or 2 files with the same name. --- There is an easier part where at least some progress can be achieved: Some of the functions restrict the caller to max_path for the total path name (not the object name), even though there doesn't seem to be a good reason. So it might be the case, that these restrictions can be lifted. However, some functions return a path and the caller might provide a buffer, that can take no more than max_path characters. These functions are more problematic, because we don't want to create buffer overruns. Here is the list of functions, which don't return paths: CopyFile2 CopyFileExW CopyFileW CreateDirectoryExW CreateDirectoryW CreateFile2 CreateFileExW CreateFileW CreateHardLinkW CreateSymbolicLinkW DeleteFileW GetCompressedFileSizeW GetFileAttributesExW GetFileAttributesW GetFullPathNameW GetLongPathNameW MoveFileExW MoveFileW MoveFileWithProgressW RemoveDirectoryW ReplaceFileW SetCurrentDirectoryW SetFileAttributesW Here is the list of functions, which return paths: FindFirstFileExW FindFirstFileNameW FindFirstFileW FindFirstStreamW FindNextFileNameW FindNextFileW FindNextStreamW GetCurrentDirectoryW GetFinalPathNameByHandleW SearchPathW --- Well, if you are talking about KernelEx for Windows 98 and Windows Millenium, we might also consider looking into the slim-character versions of the functions (for example RemoveDirectoryA) and not just the wide-character versions (for example RemoveDirectoryW). I don't know a good reason, why long paths should be limited to a specific character set used.

I can't find much information on KB2839299. Do you have a little bit extra on what was changed in fltmgr.sys?

If noone has cataloged them, then I probably have to go through them one by one.

Well, yes. I am also aware of the collections you uploaded to archive.org. But I was hoping that someone has cataloged the updates to know what's inside. It's still a long way from the state of having links to updates to the state of knowing which updates contain versions of win32k.sys. However, knowing the links is the first step. I have cataloged more than 400 Windows 2000 updates, but nearly no Windows XP updates.

Hello, as you are probably aware, Windows has problems with long paths (total length > 260 characters). --- In old Windows versions there is the "\\?\"-trick, which helps in a few situations: --- Starting with Windows 10, it is possible to allow specific applications to use longer paths. According to the documentation, Microsoft modified specific functions of the API to allow using longer paths for specific applications in Windows 10. So the list of functions is rather interesting. And here it is: CopyFileW CopyFile2 CopyFileExW CreateDirectoryW CreateDirectoryExW CreateFileW CreateFile2 CreateHardLinkW CreateSymbolicLinkW DeleteFileW FindFirstFileNameW FindFirstFileW FindFirstFileExW FindFirstStreamW FindNextFileNameW FindNextFileW FindNextStreamW GetCompressedFileSizeW GetCurrentDirectoryW GetFileAttributesW GetFileAttributesExW GetFinalPathNameByHandleW SetFileAttributesW GetFullPathNameW GetLongPathNameW MoveFileW MoveFileExW MoveFileWithProgressW RemoveDirectoryW ReplaceFileW SearchPathW SetCurrentDirectoryW --- Is anyone aware of any pioneer work that has been done to improve the situation with Windows versions older than Windows 10?

No, it didn't. No, it doesn't. No, it doesn't. No, it doesn't. No, it doesn't. No, it doesn't. After this update I stopped checking any further updates of your list. It seems as if Gemini is too buggy to create the list of updates.

Is the problem with int 13h during the part of the booting process before the driver even loaded?

Sorry for the misunderstanding, but I am looking for updates that I haven't listed, yet. There should be something like 10 or 20 different versions of win32k.sys. But I know only the 3 I listed.

Hello Windows 2000 fans, when using vanilla Windows 2000 with a rather new version of win32k.sys, there is a bug in the function "fsg_RunPreProgram" which reduces that drawing quality of some fonts. This bug was fixed with the version 5.00.2195.7610 by Microsoft. However, it was reintroduced into the operating system shortly afterwards, so it still exists in the newest version of win32k.sys (5.00.2195.7640). To fix this bug there are 2 ways: Use Extended Kernel 3.1H or newer. Blackwingcat fixed this bug. If you don't like or can't install Extended Kernel, there is now a second option available: WINDOWS2000-OTSKB3037639-V1-X86-INTL.exe There is an article in the knowledge database available with more information on the nature of this bug. There is some more auxilliary information available, which I do not plan to distribute among end users: code.htm --- If someone likes to help with an upcoming Windows 2000 update: I am looking for Windows XP updates which contain a version of win32k.sys. My list of known updates is currently pretty short: KB3013455 contains version 5.1.2600.6712 KB3034344 contains version 5.1.2600.6755 KB4039384 contains version 5.1.2600.7334 Thank you.

I think you are facing the problem that there is a specific version as a minimum requirement in the exe file. exe files, dll files and sys files are in the portable executable 32 file format. Open the file with a hex editor. The first byte (at the offset 0x0) should have the value "0x4d" ("M"). The second byte (at the offset 0x1) should have the value "0x5a" ("Z"). The 4 bytes at the offset 0x3c should contain a little endian encoded integer. Something like "12 34 56 78" which is 0x78563412. Use the integer as an offset in the file. The offset should point to a byte with the value "0x50" ("P"). The next byte should have the value "0x45" ("E"). The next byte should have the value "0x00". The next byte should also have the value "0x00". Check the 4 bytes starting at the offset from the integer + 0x40. If the file is for Windows 2000, then it should have the value "05 00 00 00". If the file is for Windows XP, then it should have the value "05 00 01 00". Reduce it to "04 00 00 00" to reduce the requirement to Windows NT 4.0. Check the 4 bytes starting at the offset from the integer + 0x48. Reduce it to "04 00 00 00". Save the file. Do not reduce the value below "03 00 01 00". --- Description of the file format: http://ontheserver.de/Downloads/entpackt/Dokumentationen/Programmierung/Betriebssystem-spezifische/Windows/Dateiformate/ausführbare Dateien und Bibliotheken/deutsch.htm

I think blackwingcat made TLS 1.3 indirectly available to Windows 2000, already. According to Wikipedia support for TLS 1.3 was added to OpenSSL 1.1.1. This version is downloadable from https://win2k.org/wlu/wluen.htm for Windows 2000. However, OpenSSL is not the native implementation of SSL/TLS for Windows 2000. The native SSL implementation of Windows 2000 is called "Secure Channel" ("schannel.dll"). According to Wikipedia support for TLS 1.3 was added to Secure Channel for releases of Windows 11 and Windows Server 2022. Another thing I just stumbled over is an update for Windows Embedded POSReady 2009: KB3055973 It adds support for TLS 128-bit & 256-bit Advanced Encryption Standard (AES) cipher suites. I don't know whether this helps in this context but it might.

Hello Anton12, you addressed your request to blackwingcat personally. Since he didn't respond for a while now, I will share my thoughts which might or might not help in getting somewhat forward with the issue. The standard "TLS 1.3" was published in 2018. The last official updates for Windows 2000 are from 2016. The last updates for Windows XP are from 2017 (I think). However, there were still updates published for Windows Embedded POSReady 2009 back in 2018. Windows Embedded POSReady 2009 is based on Windows XP and therefore is somewhat compatible with Windows 2000. So it would make sense to check whether there is an update for Windows Embedded POSReady 2009 which adds support for TLS 1.3. It would be a start to work on a solution for Windows 2000. If there is no such update, then it would be nice to know, when and how Microsoft added support for TLS 1.3 to Windows/Internet Explorer for a version as close as possible to what we have in Windows 2000. This type of research can be done without having any skills in programming. But it still helps the person whoever ends up writing the patch. There aren't many who have the skills to backport new features and write a clean and working update for end users. So the todo list of those persons are usually pretty full. Any help to reduce the burden from the bottle neck is often appreciated. Adding support for TLS 1.3 support in principle is one thing. A clean integration into the operating system is another thing. For example being able to activate/deactive support through the internet options like with the other standards would be nice, too. However, it adds more work to the undertaking.

The tests on a Windows Embedded for Point of Service (32 bits) machine are complete and have shown, that the Windows XP (32 bits) update can not be used in Windows Embedded for Point of Service (32 bits). So there is a separate update available, now. The update "WINDOWSXP-OTSKB000001-V2-X86-EMBEDDED-INTL.exe" has been released to the general public. The help file "OTSKB.chm" has been updated accordingly. The code comparison file "code.htm" has not been changed. --- Edit: There are links to new versions in the first post. --- things to do: Windows Server 2003 update: add the version "5.2.3790.6946" of the file "win32k.sys" to "code.htm" add the version "5.2.3791.0001-V1" of the file "win32k.sys" to "code.htm" add the update "Windows Server 2003/OTSKB000001-V1" to the help file write the update test it release it Windows Embedded POSReady 2009 update: add the version "5.1.2600.7684" of the file "win32k.sys" to "code.htm" add the version "5.1.2602.0001-V1" of the file "win32k.sys" to "code.htm" add the update "Windows Embedded POSReady 2009/OTSKB000001-V1" to the help file write the update test it release it