From: Etaash Mathamsetty etaash.mathamsetty@gmail.com
--- dlls/ntoskrnl.exe/ntoskrnl.rc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.rc b/dlls/ntoskrnl.exe/ntoskrnl.rc index 2faa1a35169..58c43490b38 100644 --- a/dlls/ntoskrnl.exe/ntoskrnl.rc +++ b/dlls/ntoskrnl.exe/ntoskrnl.rc @@ -18,10 +18,10 @@
#define WINE_FILENAME_STR "ntoskrnl.exe"
-/* Version as of Win 7 SP1 */ -#define WINE_FILEVERSION 6,1,7601,21863 -#define WINE_FILEVERSION_STR "6.1.7601.21863" -#define WINE_PRODUCTVERSION 6,1,7601,21863 -#define WINE_PRODUCTVERSION_STR "6.1.7601.21863" +/* Version as of Win 10 22H2 */ +#define WINE_FILEVERSION 10,0,19045,2486 +#define WINE_FILEVERSION_STR "10.0.19045.2486" +#define WINE_PRODUCTVERSION 10,0,19045,2486 +#define WINE_PRODUCTVERSION_STR "10.0.19045.2486"
#include "wine/wine_common_ver.rc"
There are plenty of other DLLs with their version set to Windows 7. Other DLLs have different Windows versions, including Windows XP, Vista, 7, 8, and 10.
Please explain why bumping the version of ntoskrnl is necessary in your commit message.
Also, I'm not sure if anything depends on the version, and if it does, the version bump may cause a regression due to unimplemented APIs.
On Sat Jan 21 19:39:51 2023 +0000, Jinoh Kang wrote:
There are plenty of other DLLs with their version set to Windows 7. Other DLLs have different Windows versions, including Windows XP, Vista, 7, 8, and 10. Please explain why bumping the version of ntoskrnl is necessary in your commit message. Also, I'm not sure if anything depends on the version, and if it does, the version bump may cause a regression due to unimplemented APIs.
I thought it could help with some software that is expecting windows 10, and ntoskrnl.exe is still updated with every windows release, so I think it's a good idea to update the version number **after** the code freeze so we can catch regressions before we release a stable version of wine.
this will probably be the last time it needs updating since microsoft probably won't make a windows NT 11.
I thought it could help with some software that is expecting windows 10,
1. It's not clear what software expecting windows 10 will actually benefit from it. A driver can fetch the version number via `RtlGetVersion` or `PsGetVersion`. A user-mode application can fetch the version number via `GetVersionEx`, `VerifyVersionInfo`, or `RtlGetVersion`.
2. Most importantly, it's not clear that the number of applications that will benefit from the change is _greater_ than the number of applications that will break because of the change. Let's assume that some applications _do_ use the file version of `ntoskrnl.exe` (via `GetFileVersionInfo` or similar). If the application determines that the Windows version is 10, and expects Windows 10 APIs that Wine has no implementation for, it will fail. Moreover, some applications will expect a version _older than_ Windows 10, and fail if the criteria are not satisfied.
and ntoskrnl.exe is still updated with every windows release, so I think it's a good idea to update the version number
If we want to match file version numbers from Windows, then we'll need another method for that since _every_ Windows quality update that involves the kernel will get the version bump.
**after** the code freeze so we can catch regressions before we release a stable version of wine.
Right. I think you've explained _how_ to catch regressions, but you'll have to state a convincing _why_.
this will probably be the last time it needs updating since microsoft probably won't make a windows NT 11.
I'm not sure what you're referring to as "windows NT 11." Windows 11, which was released October 2022, starts with the internal version number 10.0.22000, and it's indeed unlikely that Microsoft will bump the major component of the internal version from 10. This means that applications will read the build number instead. If I understood your comment correctly, you're saying that we'll have to bump the version number every time Windows has an update.
I guess the general approach (not necessarily applicable to every particular case) is that if a component’s version bump is needed to make something work we should do it as it is the way forward. Counting apps which will get broken of fixed is hardly possible, also we can’t be stuck on the old version forever. If some apps breaks due to now requiring more stuff then the way forward is to implement missing bits.
On the other side, if nothing is known to be fixed by the version bump it is not apparent that touching the version number worth it, maybe it would be more useful to implement something from the new version first.
On Mon Jan 23 01:27:35 2023 +0000, **** wrote:
Paul Gofman replied on the mailing list:
I guess the general approach (not necessarily applicable to every particular case) is that if a component’s version bump is needed to make something work we should do it as it is the way forward. Counting apps which will get broken of fixed is hardly possible, also we can’t be stuck on the old version forever. If some apps breaks due to now requiring more stuff then the way forward is to implement missing bits. On the other side, if nothing is known to be fixed by the version bump it is not apparent that touching the version number worth it, maybe it would be more useful to implement something from the new version first.
I meant that we won't have to update it much after this update, since microsoft won't start the build number with 11.x and I guess I have to find some usages of this version resource
This merge request was closed by Etaash Mathamsetty.
-
Etaash Mathamsetty -
Etaash Mathamsetty (＠etaash.mathamsetty)
-
Jinoh Kang (＠iamahuman)
-
Paul Gofman