Your analogy is imperfect; for MSHTML and EdgeHTML are first-party, while Electron is third-party; and it’s not just MSHTML that Microsoft are pushing people away from, but the entire Win32 API—Microsoft’s been saying, use WinRT instead, and you can have EdgeHTML there. Notably, Microsoft has been steadily stepping back from this vision in the last few years, and EdgeHTML is expected to be exposed to Win32 apps at some point (the impression I have is that it is expected sooner rather than later).
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.)
Sure the analogy is imperfect. I also don't have a perfect analogy for a browser vendor hobbling its newer product. But I'm just appealing to common sense wrt not addressing an extremely common use of something yet wanting that something to stop being used.
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.
It's less about hobbling Edge and more about compelling you to not use Win32 while keeping you stuck in Windows. Win32 needs to die and Microsoft is doing everything it can to kill it while not completely pissing off those that rely upon it.
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.
I'm pretty sure it's not going away, especially because the newer more bloated stuff they're trying to push is built on top of it, and that's not going to change unless MS decides to start officially documenting the native NTAPI.
They day they get rid of Win32 is the day I switch completely to Linux+WINE or even ReactOS.
Such as? Products like Office have undergone significant refactoring to remove reliance on Win32. They have something like over 90% code reuse between Office apps on MacOS, OSX, Android, Win32, and Xaml.
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.
> 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.
> Both those articles are heavy on marketing and light on detail
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.
Well, that's true if the problems aren't with the platform's browser, though in this case you would probably just ship a CEF or WebKit2-based runtime to replace MSHTML/EdgeHTML.
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.)