FuzzleSnuz

The blind leading the blind, anyone...? Do you know what an API is? It's easy for non-programmers to confuse an application programming interface concept with implementations of that interface. API: - https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_2/nn-dxgi1_2-idxgiadapter2 - https://learn.microsoft.com/en-us/windows/win32/api/d3d11_1/nn-d3d11_1-id3d11device1 KB2670838's versions of dxgi.dll, d3d11.dll, and co provide this API. The associated symbols and structures of this API exist on Windows 7. They are exported. They are callable. No access violations. Try arguing that this application programming interface does not exist on 7 to the programs which interface with it on 7. As I already explained, it was provided on 7 to simplify code for applications that expected Windows Store distribution but wanted to maintain less separate logic for d3d devices on 7 vs 8. The differing implementation of the API on 7 vs 8 doesn't magically invalidate the fact that this API exists on both platforms. That's why we have a difference between interface and implementations. Upgrade's implementation has the shiny new features. Downlevel's implementation might be full of ERROR_UNSUPPORTED query results. Interface ≠ implementation. Here, you can educate yourself regarding the topic. - Step 1: Any introduction to C book will do. Or, since you fancy yourself a programmer, you can jump to this book that Google found regarding interfaces and implementations: http://www.r-5.org/files/books/computers/languages/c/mod/David_R_Hanson-C_Interfaces_and_Implementations-EN.pdf - Step 2: Refer to msdn: https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_2/ Accurate documentation with precise explanations. You can write a sample program to observe how these things work, if you don't believe the literature. Here's a springboard for you: https://walbourn.github.io/anatomy-of-direct3d-11-create-device/ from legendary DirectX team member Chuck Walbourn. Do you know what a feature level is? Microsoft terminology is admittedly a little muddy regarding this, but it becomes apparent while working on these kind of programs. https://learn.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-devices-downlevel-intro I was talking D3D11 feature levels, not 12, so let's use this link about D3D11 Feature Levels, not your link about D3D12 Hardware Feature Levels. These are different things. If you can't figure it out, here are precise and simple explanations for you: - Windows implements Feature Levels. The D3D11.1 API (remember what an "API" is?) is the interface between your application and the abilities of the Feature Level you want. A lack of the Feature Level you want does not magically mean the API has ceased to exist. - Graphics drivers implement Hardware Feature Levels and advertise their compatibility with them. When your application uses the D3D11.1 API to request an ability of the 11_1 feature level from Windows, Windows in turn must request that ability from the graphics device driver, which in turn can only offer that ability if the graphics device hardware is capable of it and the graphics driver is programmed to drive said ability. Feature Level ≠ Hardware Feature Level. Mono knows there is no 11_1 feature level on 7 and does not bother trying to acquire an ID3D11Device1. Again, you have entirely failed to understand why KB2670838 was created and why it does what it does. Microsoft policy required all Microsoft Store programs to use the D3D11.1 API when using the machine's graphics device. There was (and still is) absolutely zero need for Mono to become compatible with distribution on the Microsoft Store. KB2670838 was a simple standardization effort to reduce manhours of programmer labor and conform to manufacturing requirements. It happens all the time. KB2670838 was never about blessing Windows 7 users with the shiny new Windows 8 features. That would reduce Windows 8 sales. It was about saving costs. Just like how the similar D3D11 platform update for Vista was never about enabling Vista users to play D3D11 games. It was about reducing manhours of programmer labor in the Internet Explorer team to enable a single codebase from which IE 9, 10, and 11 could all be built as efficiently as possibly. Vista needed to be uplifted to the D3D11 common denominator of that unified code base to enable its continued contractual servicing. These are just ABCs of standard software development. APIs provide stability and insurance against time and varying implementations. Your program talks to Windows API to get an implementation. Windows talks to the graphics driver API to get an implementation. The graphics driver talks to the hardware to get a result. Just because one of these links in the chain doesn't exist and you don't like that (11_1 feature level), does not magically mean that the rest of it doesn't exist either (D3D11.1 API). Someone somewhere once said, "if you aren't a programmer, don't blah blah..." ...especially if you are going to be arrogant, rude, & condescending about something you don't know. And hijack a random person's thread, no less! I created this thread to try to find a solution to a problem I'm facing. You get the satisfaction of derailing my attempt to find a solution, and I get the fun chore of having to clean up the dump you took in this thread. Ironic. This was the thread you followed me from, btw. Shame on me for making a post in that thread. It was only my fourth post on MSFN and within 48 hours I ended up on the radar of two trolls itching for a fight. I thought MSFN was better than that.

I had a post in here. It's gone now. Why was it deleted? I didn't do that. The only remnants of it are from someone who quoted my now-redacted post. The quoter in question falsely accuses the forks of VxKex (links I shared to help document this issue) to be "fake", even though they clearly originate from VxKex and possessing no changes. Perhaps he fails to understand github? Did this quoter have the power to delete my post under the premise of the lie he put forth? Otherwise, it must have been a moderator. In that case, what rule was violated by my post? I didn't receive any message explaining a violation of MSFN rules. I fail to see how my post of accurate documentation on the reality of the VxKex situation violated MSFN T&C. Please explain why my post was removed without warning.

Did you read the OP? No one here has argued that the complete "D3D11.1" experience (circa 6.2) is present in 7. You've completely missed the entire point of this thread. Fixing the lack of complete 11.1 on 7 requires an implicit understanding that the there is no complete 11.1 on 7. And that is obvious if you read the OP. Additionally, this: "Windows 7 never supported D3D11.1." is a rumor/fake news. To broadly say "D3D11.1" means referring to both the 11.1 API (IDXGIAdapter2) and the 11_1 feature level. With KB2670838 installed on 7, the API is supported, while the feature level is not. - Microsoft brought the 11.1 API to 7 to enable developers to consolidate similar code (and save manhours) for projects that targeted both 7 and the 8 Windows Store, during that transition period. Windows Store policy dictated conformance to a standard/sanctionable interface, which MS chose to be the 11.1 API. Conveniently, this was only one degree of separation apart from the equivalent on the previous OS. - The 11_1 feature level, however, was never implemented in KB2670838. Perhaps this is what you were trying to say? But again, everyone who has programmed in this capacity already knows this. No one in this thread was trying to argue against that. Your counterargument wasn't countering anyone. Lastly, it may be entirely possible to implement specific key features of WDDM 1.2 (like flip chains and the newer gpu preemption) on 7 without the 11_1 feature level. Those are the only two things I particularly care about right now, though obviously having feature level 11_1 or higher on 7 would be great.

Maybe there is another Chris Sawyer out there who can make sense of disassembled NT 6 code Plus, Jaguarek62 himself knows a thing or two.

Some versions of Autodesk Maya. For Maya, it's not a technological support issue but rather a "we only bothered testing on Win 7 and 10" kind of thing. There isn't any anti-Win8 behavior as far as I can tell, but there could be a mountain of showstopping bugs that aren't immediately evident. It was a decision driven by the leverage of Autodesk's enterprise clients, who were only using 7 and 10 at the time and thus pressured Autodesk to do the same. This isn't uncommon. This is only partially true. I have 365 installed on my machine and it receives "security updates only". Microsoft decided to do a freebie ESU program for 365 on Win 7. Ofc 365 is dysfunctional spyware and I use 2010 whenever I can.

This was a hot topic back in 2012, and we all know how Microsoft gave up halfway when they brought the D3D11.1 API to Win 7 but didn't bother bringing WDDM 1.2 along with it. That was now ten years ago. Since then, especially in recent years, there have been some great projects that make the better versions of Windows remain viable in these dark, modern times. I'm thinking of things like the extended kernels for Vista, the Win 8 xHCI driver stack brought to Win 7, and even 12on7 by Microsoft themselves. I even see some talk about making extended Win 7 and 8 kernels now, given that the right person (or people) with the right knowledge shows up to do it. Given the recent progress with these kind of things, I would like to know if anyone, anyone at all, is aware of a current-day effort to get WDDM 1.2 functional on Windows 7. By functional, I mean something that makes it possible to install a Win 8 graphics driver in order to benefit from the improvements in WDDM 1.2, like the superior GPU preemption model. For certain graphics applications that abandoned Win 8 early but kept Win 7 support, this would be an incredibly helpful thing to have.