Then allow me to use Edge as a Windows control a la MSHTML in a non-UWP app. It's like if Chrome were suddenly made close source and non-embeddable and then Google complaining about insecure Electron apps.
It’s a nuisance that it isn’t already there, but it is coming.
Note also that Chromium isn’t embeddable on its own; it’s only because it’s open source that anything has been able to embed it at all. It has no stable API, so CEF has to wrap it and shed some functionality to ensure it’ll keep working across more than just a few releases of Chromium, as changes are made therein. The Electron project basically builds itself inside Chromium instead, see https://electronjs.org/blog/electron-internals-building-chro....
But really, IE has enough things needing it that removing it outright isn’t an option yet, and won’t be for quite a few years. I can imagine in a few years’ time not installing IE by default, and making the MSHTML widget actually be EdgeHTML instead if IE’s not installed, but even that I expect would break quite a bit of software. And Microsoft cares a lot about not breaking compatibility. It’ll be interesting to see what they do about it.
(You may well know these points already, kodablah; I’m providing them as much for background for others reading as for you.)
I personally don't think they should implement the MSHTML/COM APIs with Edge any more than I think they should implement ActiveX on Edge. The old tech can die its slow death, so long as there is a viable replacement.
Selfishly, I want this for https://github.com/zserge/webview to watch Electron adoption decrease or even an API-compat version using shared libs already on the system.
Part of the problem is that if they force everyone to rewrite Win32 native apps then what's stopping them from just going to MacOS or something else?
They want everyone off Win32 but still locked into Windows.
They day they get rid of Win32 is the day I switch completely to Linux+WINE or even ReactOS.
With every release of Windows 10, more and more GDI and Win32 is replaced.
Part of the MinWin project was to extricate Win32 from the kernel and have a true separation.
https://referencesource.microsoft.com/#mscorlib/microsoft/wi...
Products like Office have undergone significant refactoring to remove reliance on Win32.
Then what are they using instead? Whatever it is, how does it provide the basic functions? Does it call into native NT API directly?
Part of the MinWin project was to extricate Win32 from the kernel and have a true separation.
What? Win32 is not part of the kernel, it's a layer on top of the native NT API (or VMM32, if you remember Win9x...)
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
https://en.wikibooks.org/wiki/X86_Disassembly/Microsoft_Wind...
They use a PAL, each platform has it's own PAL and the Windows Kernel as two (WinRT and Win32).
https://www.zdnet.com/article/how-microsoft-is-taking-on-the...
> What? Win32 is not part of the kernel, it's a layer on top of the native NT API (or VMM32, if you remember Win9x...)
It wasn't. When WinNT hit the scene in the 90s there was definitely a distinction between Userland and Kernel space but by XP there was so much encroachment. MinWin was the creation of horizontal layers of separation.
https://betanews.com/2009/12/02/mark-russinovich-on-minwin-t...
https://arstechnica.com/information-technology/2016/12/how-a...
...the "PAL" is basically the Win32 libraries with a different interface on the other side (in some ways, like WINE), so no, Win32 is not going away.
And? Does that somehow invalidate my arguement? The Betanews article is an interview with Mark Russinovich, the Chief Technology Officer for Azure at Microsoft. And as the article says, Microsoft has been making a concerted effort to extricate Win32 from the Kernel and making it an isolated Subsystem as it originally was.
> The principal division of labor in Win32 has historically been vertical, not horizontal, dividing core system kernel functions from "user" input and interactive functions, from graphics and display functions. Even though Windows architecture has evolved to the point where the whole graphics part is essentially deprecated for modern apps, GDI32.DLL is presumed to be present.
The zdnet article is based off a presentation that Microsoft gave at CppCon talking about how they made Microsoft Office Cross Platform. The PAL concept is similar to the HAL in Windows but specific to Office. They very well could have created different PALs that implemented the Win32 API but they didn't.
There are two versions of Office for Windows, one implemented using Win32 and one using WinRT/UWP. The former is mostly around because Microsoft is still supporting versions of Windows prior to 8.
WinRT on Windows 8 actually is a wrapper on top of Win32 but what does that matter?
> if the PAL they're talking about is anything like the one described here... > ...the "PAL" is basically the Win32 libraries with a different interface on the other side (in some ways, like WINE), so no, Win32 is not going away.
So you ask if Drawbridge is the PAL used in Office and then you state that it is in fact the same thus proving that Win32 isn't going away? Drawbridge was born out of a Microsoft Research project in 2011, the talk about Office's PAL is from 2007 and describes something different.
You also didn't bother to read your own article because it states that SQL's PAL emulates about 1% of Win32 API, just enough to run SQL Server and their goal is to remove internal abstractions and merge down all code just above the host extension layer. In other words, get rid of Win32 emulation and the SQLOS abstractions.
https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie...
[1] Notably not a problem that affects Internet Explorer, nor (obviously) Firefox, Chrome or Safari.
The new one also has reasonably sized UI elements ie smaller.
A) It doesn't matter you're a "mac user".
B) It's a technical fault, not "unprofessional"
I can, however, if I squint, just about see the argument for why it's taken so long to fix: I suspect it probably wasn't seen as that valuable for the kind of apps and sites that Microsoft think people mostly use the web for. Thing is, get off the beaten path slightly, and you find people using the web for all kinds of interesting and creative things: demos, games, music players and editors, emulators, synthesizers and instruments, image and video manipulation.
And there is a school of thought (to which I don't belong) that says all apps should run in the browser. But if that's ever going to happen, massive and inconsistent input latency of any kind is not something that can be tolerated. Even if we don't go that far, and I suspect we won't, there are still a wide range of web apps for which unpredictable input latency is not acceptable.
So I suppose what I'm saying in a very long winded-way, is that I agree it shouldn't have been there for so long, although I don't think I'd call it unprofessional.
That does use C++/CLI though, but I'm sure you can play around with the embedded api if you really want a pure C++ solution.
[0] https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc...