That adds various NT 6 APIs and even compatibility modes for various newer versions of Windows up to Windows 11. At a glance, it appears to have support for Vulkan, Direct3D 10 and Direct3D 11 through software rendering, with the option of using WineD3D to get hardware accelerated Direct3D 10 and 11. I assume old WineD3D-PBA binaries run very nicely on that.
Interestingly, the developer suggests that installing graphics drivers from newer versions of Windows might be possible at some point, which I assume would provide native hardware acceleration for newer graphics APIs and support for recent graphics cards:
> WDDM is not impossible, only very hard. Currently initializes and the subsystem runs, but every driver fails to communicate with it's internal hardware due 2000/XP/2003 doesn't have support for MSI/MSI-X interrupt, required to WDDM drivers works;
Are the outcomes in the US worse? Not that long ago (a couple months ago in fact), I looked at public data comparing cancer survival rates, which put the outcomes in the US at least 10% better than those in the UK. That was additive, such that a 20% survival rate in the UK for a type of cancer is at least a 30% survival rate in the US. The 10%+ better outcome in the US applied to all types of cancers for which I found public data.
I believe the reason for higher US success rates was that the US used more aggressive treatments that the UK would not, since neither does the NHS pay for them nor do their doctors offer them. It is easy to complain about the US system, but the reason that the per capita cost of health care in the US is high could be because the US will try expensive things that the UK’s NHS never would have attempted (since spending exorbitant amounts on aggressive treatments with low chances of success to attain US success rates would drive the per capita cost of medicine to what could be US levels). The high US pricing of those treatments could be further amplified by attempts to take advantage of ignorance. Amplification to take advantage of ignorance was clearly the case in the article author’s case.
I feel like the opposite viewpoint in favor of the US system is not well represented in online discourse, which could very well be because those who were not served well by the UK’s NHS are dead. There are anecdotes about people coming to the US for treatments that they could not receive in the UK or Europe, which is consistent with that.
That said, I have only looked at data for cancer survival rates and not other illnesses, but the cancer data alone contradicts what you wrote. Perhaps reality is in the middle where the UK system is better for routine issues (i.e. you avoid sticker shock), but the US system is better for anything that falls outside of that (i.e. you have a better chance to live). There is evidence both systems have plenty of room for improvement.
Cancer rates are hard to compare across countries because overdiagnosis is such a common issue.
A higher survival rate is to be expected when the doctors have a financial incentive to treat benign growths which the patient would have survived anyway. It can indicate overdiagnosis rather than indicating successful treatment.
You're taking quite a small view of healthcare in the end looking at only cancer outcomes. Just ignoring things like maternal mortality, infant mortality, cardiovascular issues, etc.
You are right, but blanket statements only need one counter example to be shown to be false. I had looked into cancer data because I read some remarks made about cancer between the US and Europe and I was curious if they were true.
For what it is worth, I take a prescription medication for a non-life threatening condition. I had once called Costco in Canada to find out how much the price is there out of curiosity. They do not sell it. I then discovered that the drug my doctor prescribed is exclusive to the US and is not sold anywhere else in the world. Presumably, nobody else is willing to pay the exorbitant price that is charged for it. Even the generic is expensive. The US system is expensive, but it gives people access to more expensive treatments that simply are not available elsewhere.
That said, I might have an elective operation in the future. It would have been covered by insurance as a necessity when I was young, but my parents never pursued it and the underlying condition’s severity decreased when I became an adult such that it is now elective surgery. I expect to engage in medical tourism to have that done.
Getting rid of the BIOS sounds awesome. I assume that means that it gets rid of code running the SMM, which can prevent invisible code from sapping performance from the machine for no apparent reason. For example, on recent AMD machines, such as my Zen 3 machine, memory bandwidth measured by ZFS' checksum algorithms will randomly drop by a significant percentage and there is no obvious reason why, although I suspect patrol scrubs are involved.
That begs the question. What does the patrol scrubs of ECC memory on your hardware?
1. Implementing PR_SET_SYSCALL_USER_DISPATCH
2. Implementing ntsync
3. Implementing OpenGL 4.6 support (currently only OpenGL 4.1 is supported)
4. Implementing Vulkan 1.4 with various extensions used by DXVK and vkd3d-proton.
That said, there are alternatives to those things.
1. Not implementing this would just break games like Jurassic World where DRM hard codes Windows syscalls. I do not believe that there are many of these, although I could be wrong.
2. There is https://github.com/marzent/wine-msync, although implementing ntsync in the XNU kernel would be better.
3. The latest OpenGL isn't that important these days now that Vulkan has been widely adopted, although having the latest version would be nice to have for parity. Not many things would suffer if it were omitted.
4. They could add the things needed for MoltenVK to support Vulkan 1.4 with those extensions on top of Metal:
It is a shame that they do not work with Valve on these things. If they did, Proton likely would be supported for MacOS from within Steam and the GPTK would benefit.
I wonder if paying the boring company to make a tunnel for the cables would be cost effective and avoid complaints. I believe that they can bore tunnels without digging along the path on the surface.
Horizontal drilling is already part of the plan in many places - Elon Musk isn't the first person to think of it. It still costs loads to do it per mile - by the looks of it you'd have six bores with three cables each (or one or two much larger bores). And a deep, concrete-sheathed cable is a huge pain to maintain compared to cables around 1-3m underground.
If you are willing to give up incremental compilation, concatenating all C++ files into a single file and compiling that on a single core will often outperform a multi-core compilation. The reason is that the compiler spends most of its time parsing headers and when you concentrate everything into a single file (use the C preprocessor for this), it only needs to parse headers once.
Merely parsing C++ code requires a higher time complexity than parsing C code (linear time parsers cannot be used for C++), which is likely where part of the long compile times originate. I believe the parsing complexity is related to templates (and the headers are full of them), but there might be other parts that also contribute to it. Having to deal with far more abstractions is likely another part.
That said, I have been incrementally rewriting a C++ code base at a health care startup into a subset of C with the goal of replacing the C++ compiler with a C compiler. The closer the codebase comes to being C, the faster it builds.
GCC was originally written in GNU C. Around GCC 4.9, its developers decided to switch to a subset of C++ to use certain features, but if you look at the codebase, you will see that much of it is still GNU C, compiled as GNU C++.
There is nothing you can do in C++ that you cannot do in C due to Turing Completeness. Many common things have ways of being done in C that work equally well or even better. For example, you can use balanced binary search trees in C without type errors creating enormous error messages from types that are sentences if not paragraphs long. Just grab BSD’s sys/tree.h, illumnos’ libuutil or glib for some easy to use balanced binary search trees in C.
> There is nothing you can do in C++ that you cannot do in C due to Turing Completeness.
While this is technically true, a more satisfying rationale is provided by Stroustrup here[0].
> Many common things have ways of being done in C that work equally well or even better. For example, you can use balanced binary search trees in C without type errors creating enormous error messages from types that are sentences if not paragraphs long. Just grab BSD’s sys/tree.h, illumnos’ libuutil or glib for some easy to use balanced binary search trees in C.
Constructs such as sys/tree.h[1] replicate the functionality of C++ classes and templates via the C macro processor. While they are quite useful, asserting that macro-based definitions provide the same type safety as C++ types is simply not true.
As to the whether macro use results in "creating enormous error messages" or not, that depends on the result of the textual substitution. I can assure you that I have seen reams of C compilation error messages due to invalid macro definitions and/or usage.
It depends on the codebase. If the code base deserves to be a case study in how not to do programming, then a rewrite will definitely yield better results.
I once encountered this situation with C# code written by an undergraduate, rewrote it from scratch in C++ and got a better result. In hindsight, the result would have been even better in C since I spent about 80% of my time fighting with C++ to try to use every language feature possible. I had just graduated from college and my code whole better, did a number of things wrong too (although far fewer to my credit). I look back at it in hindsight and think less is more when it comes to language features.
I actually am currently maintaining that codebase at a health care startup (I left shortly after it was founded and rejoined not that long ago). I am incrementally rewriting it to use a C subset of C++ whenever I need to make a change to it. At some point, I expect to compile it as C and put C++ behind me.
Data structures like maps and vectors from the standard library are still incredibly useful and make a fantastic addition to C if your focus relies on POD types, though if real time performance with heap cohesion is a problem then you’re right to go pure C
I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C.
Problem 1: You might fail to initialize an object in memory correctly.
Solution 1: Constructors.
Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call.
Solution 2: Placement new
Problem 3: Now the type system has led the compiler to assume your preallocated memory cannot change since you declared it const.
Solution 3: std::launder()
If it is not clear what I mean about placement new and const needing std::lauder(), see this:
C has a very simple solution that avoids this chain. Use structured programming to initialize your objects correctly. You are not going to escape the need to do this with C++, but you are guaranteed to have to consider a great many things in C++ that would not have needed consideration in C since C avoided the slippery slope of syntactic sugar that C++ took.
But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.
That's a false comparison. There's a huge difference between a standard container library, and the combination of a (a) best-in-class byte code interpreter with a (b) caching, optimizing JIT, supported by (c) a best-in-class garbage collector.
I would argue that it's reasonable to say that creating a robust data structure library at the level of the STL shouldn't be that arcane.
Problem 1 happens, say, 10% of the time when using a C struct.
Problem 2 happens only when doing SLAB allocations - say, 1% of the time when using a C++ class. (Might be more or less, depending on what problem space you're in.)
Problem 3 happens only if you are also declaring your allocated stuff const - say, maybe 20% of the time?
So, while not perfect, each solution solves most of the problem for most of the people. Complaining about std::launder is complaining that solution 2 wasn't perfect; it's not in any way an argument that solution 1 wasn't massively better than problem 1.
I absolutely agree - your chain of reasoning follows as well.
It doesn't seem like it at first, but the often praised constructor/destructor is actually a source of incredible complexity, probably more than virtual.
https://archive.org/details/smallest-windows-xp-rtm-sp-0
I assume the minimal version of Windows XP still has components that were stripped out of this version of windows 7.