Feedback: Direct3D 12 interop page needs work

[clandrew]

Link to article:
https://docs.microsoft.com/en-us/windows/desktop/direct3d12/direct3d-12-with-direct3d-11--direct-2d-and-gdi#interop-apis

See the section at the bottom under "Interop APIs".

[ryanmajidi]

@GrantMeStrength Can you please take a look at this issue?

[stevewhims]

For this, I’ve created a User Story for myself: https://dev.azure.com/ceapex/Windows%20Dev%20Content/_workitems/edit/102806.

Do you know exactly what changes need to be made? Or a contact who can help put the content together?

[clandrew]

It might be enough to link to these:
https://docs.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-id3d12device-createsharedhandle
https://docs.microsoft.com/en-us/windows/desktop/direct3d12/direct3d-11-on-12

Between these two pages it covers much of the API surface for the kinds of interop listed out at the top.
If you want something more in depth you can get in touch with me/Jesse/d3ddev although it's unlikely to be something we can get to very soon

[stevewhims]

I think that amount of info feels right for this workstream. So, I just merged https://github.com/MicrosoftDocs/win32-pr/pull/128. I don't know when that merge will make its way to the live site; win32-pr has been very slow for me the past 24 hours.

[nschonni]

@stevewhims do you know if there are plans for a public win32 repo?

[stevewhims]

I'm not aware of a schedule, nor firm plans.

[nschonni]

no worries, I thought I'd ask since a chunk of the stuff that ends up in this repo is related to that content. An open issue tracker with the comment integration would be helpful, event if the content isn't

[stevewhims]

Ok, the fix is now live (https://docs.microsoft.com/windows/win32/direct3d12/direct3d-12-with-direct3d-11--direct-2d-and-gdi#interop-apis); ready to close.

[nschonni]

FYI, your last link has the "en-us" hardcoded in the URL, and that will break the localization

[stevewhims]

Thanks for taking a close look, Nick, I will kick off an investigation internally as to what's going on here. The issue that you're seeing might be fallout from a recent change made to our build system, but it's not a problem with the authoring.

It is, as you say, very important not to hardcode the language tag into any link. Here, the source .md file in our content management system (CMS) contains no language tags. The link in question appears in that .md file as the site-relative link "/windows/win32/api/d3d12/nf-d3d12-id3d12device-createsharedhandle". And that's how it should be; that's how we recommend links be authored in markdown.

However, our content build system then works on that markdown source to generate other, downstream, artifacts, and ultimately you can view a different "page source" via the browser. All else being equal (which it isn't, as I'll get to :)), a link in the format that I authored will be transformed, by the time the reader clicks it, into an absolute url with the lang tag most appropriate to their system/browser settings.

But there was a change made to the system this week. An engineering change was made to the URLs related to the win32-pr repo. They changed the "desktop" part of the URL to "win32" (and there was some infrastructure set up around redirecting from old "desktop" URLs to the equivalent new "win32" URL). And possibly they plan to go through the CMS and update all URLs. But in any case, in my markdown, I used the new "win32" segment (although I'm seeing the exact same problem with relative links using the old "desktop" segment). But by the time my markdown was transformed by the build system, the browser "page source" did indeed contain "en-us" for any relative link, whether it was a "desktop" or a "win32" one.

What I'm seeing, at least for the win32-pr repo, is that absolute links (sans lang tags) are working fine for other locales. But relative links (like the one I'm using, and which is the preferred way) are not (I'm even seeing "en-us" in the page source even from a ja-JP-locale browser). I haven't seen issues like this before, so I'm wondering whether the problem here is linked to this recent change, just b/c it was recent.

In any case, what I'll do here is to report the issue to my contacts internally and we'll see whether we can track down the cause. I don't want to work around the problem by putting absolute links into my markdown, since that's just busy work and will need to be reverted back to the preferred format after the real issue is fixed.

So, leave this with me, I'll track it until it's resolved.

~Steve

[nschonni]

:+1: it's possible that someone put the language tag into the .openpublishing.redirection.json (sorry, I've PR'd to too many docs repos :wink: )
FYI, on the en-ca, i'm seeing the reverse, where the relative links are fine, but the third absolute has the locale

<ul>
<li><a href="directx-12-getting-started" data-linktype="relative-path">Understanding Direct3D 12</a></li>
<li><a href="direct3d-12-interop" data-linktype="relative-path">Working with Direct3D 11, Direct3D 10 and Direct2D</a></li>
<li class="x-hidden-focus"><a href="/en-us/windows/win32/direct3d12/direct3d-11-on-12" data-linktype="absolute-path">Direct3D 11 on 12</a></li>
</ul>

[stevewhims]

That's the kind of thing, but there's no "en-us" in the redirection file for this repo. But, yeah, I'm sure it'll turn out to be a config issue like that. Doing some experimentation here and comparing behavior of topics in windows-uwp-pr and win32-pr, I'm seeing a different value for contentLocale being set in the script in the page source. For windows-uwp-pr, contentLocale is set to the browser locale, and relative links are getting that same value in the page source. For win32-pr, SOME loc-related settings are set to the browser local, but the (apparently) important contentLocale is pegged to en-us. So that's what appears in page source for rel links. I've passed along this info and I'll follow up. Thanks again for your care in finding this, Nick! ~Steve

[stevewhims]

This has been resolved for a while; closing.