8388842: VER_PLATFORM_WIN32_NT checks in WPrinterJob are obsolete

[MBaesken]

At some places in the coding we still check for VER_PLATFORM_WIN32_NT, but this should be obsolete.
All Windows versions from at least Windows XP fall in this category
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-osversioninfoa

There is another usage in java.base (java.base/windows/native/libjava/java_props_md.c), I can handle this here or do the java.base adjustment in another PR.

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8388842: VER_PLATFORM_WIN32_NT checks in WPrinterJob are obsolete (Bug - P4)

Reviewers

• Phil Race (@prrace - Reviewer)
• Christoph Langer (@RealCLanger - Reviewer)
• Lutz Schmidt (@RealLucy - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/32037/head:pull/32037
$ git checkout pull/32037

Update a local copy of the PR:
$ git checkout pull/32037
$ git pull https://git.openjdk.org/jdk.git pull/32037/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 32037

View PR using the GUI difftool:
$ git pr show -t 32037

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/32037.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[MBaesken]

I added a return value check to GlobalAlloc, seems we check this usually and should do so according to the function documentation at https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc .

[openjdk]

@MBaesken This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8388842: VER_PLATFORM_WIN32_NT checks in WPrinterJob are obsolete

Reviewed-by: prr, clanger, lucy

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 8 new commits pushed to the master branch:

• 3412d4c: 8387722: The race during initialization or lazy constants in and Map/Set
• 97544c7: 8321012: RISC-V: C2 ExtractUB
• 67afba7: 8364025: MinMaxVector clipping range benchmark highestInt/Long can overflow
• ... and 5 more: https://git.openjdk.org/jdk/compare/8f8c73302ee7cd3d9ba61a6825eee933d2fa009a...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@MBaesken The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[openjdk]

The total number of required reviews for this PR has been set to 2 based on the presence of this label: client. This can be overridden with the /reviewers command.

[mlbridge]

Webrevs

• 00: Full (0ad5a2da)

[prrace]

There is another usage in java.base (java.base/windows/native/libjava/java_props_md.c), I can handle this here or do the java.base adjustment in another

In the JBS issue I already commented that I found this too, and it should be done separately, if at all.

The better question is why you aren't doing the other desktop one I pointed out, in

java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp

[prrace]

There is another usage in java.base (java.base/windows/native/libjava/java_props_md.c), I can handle this here or do the java.base adjustment in another

In the JBS issue I already commented that I found this too, and it should be done separately, if at all.

The better question is why you aren't doing the other desktop one I pointed out, in

java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp

Oh, I see .. this is currently being removed by a different PR
https://github.com/openjdk/jdk/pull/32011/changes#diff-f10c72c1bbee6a44a5361e575f69e6ef09e69ae317536dec76d04cf062242667

Hmm, perhaps this should have been added to that PR but never mind .. that's all about D3D

[RealLucy]

LGTM.