> despite efforts from Microsoft to move on to the more modern Edge.
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.
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.
Not to mention, Microsft, please fix the keyboard event latency in Edge[1]. It makes anything vaguely interactive, especially games, nigh on unusable, unless you particularly enjoy dying on a regular basis because the browser took 300ms to notice you'd pressed a key.
[1] Notably not a problem that affects Internet Explorer, nor (obviously) Firefox, Chrome or Safari.
It's certainly been in there for as long as I've been using Windows 10; not sure about before that. It was super-frustrating because it affected both keyDown and keyUp, and it was also completely inconsistent.
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.
I saw this as part of https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a... (and the previous cppwinrt github project) but I haven't dug too deeply. I wonder if the restrictions are too limiting. Any bare-bones win32 example of using it in a simple cpp file? I plan on doing a poc myself soon.
Using WinRT stuff in a Win32 app is quite simple. Add windowsapp.lib, #include "winrt/Windows.Foundation.h", and call winrt::init_apartment();. There's no easy way to embed Xaml controls, though. I think the only option would be to have a separate Xaml window, get its HWND, and SetWindowLong+SetParent to force it to be a child window.
Well, the controls in question here are WPF and WinForms hosts for UWP controls, so if you can host WPF then you can use the UWP host control to host UWP content. Yeah, its a bit roundabouts, but I think it is the only supported way right now.
As a long-time IE (and Chromium, Firefox, and Opera --- I don't really have any particular "allegiance" with browsers --- I have two of those open at the moment with different sites) user, what really makes me refuse to use Edge the most is the dumbed-down UI. I'd be perfectly happy if they took its rendering engine and put it in the "normal" IE UI, and kept all the configurability too.
I don’t think the current title “internet explorer 0-day discovered” is correct.
An new way to exploit the zero-day was discovered. But not bug itself.
In late April, two security companies (Qihoo360 and Kaspersky) independently discovered a zero-day for Internet Explorer (CVE-2018-8174), which was used in targeted attacks for espionage purposes. This marks two years since a zero-day has been found (CVE-2016-0189 being the latest one) in the browser that won’t die, despite efforts from Microsoft to move on to the more modern Edge.
The irony is that Microsoft never supported NPAPI in Edge to improve security, and left NPAPI in IE11 indefinitely so any business (which is millions) stuck on NPAPI are left using IE11 for many years to come (Java Applets, Flash, ActiveX, etc).
It is one of those decisions taken with the best possible motives, but that will have massive unintended consequences and keep IE11 on life-support well into the 2020s.
One can also simply disable IE by going through Windows' Turn On/Off Windows Features menu. I wonder why do they not do it by default if they want their users to use Edge ahead of any alternatives.
Microsoft has Edge, no need for IE besides backward compatibility for ActiveX and VBScript and such things that some enterprises might still depend on. It's actually amazing how long Microsoft supports things compared to others in the industry.
I make that argument myself fairly often, but IE should go away. Microsoft would prefer users use Edge, and are not updating IE except for security patches. So while I will join you in railing against people who say everyone should adopt [browser of choice here], I don't have a problem saying Microsoft IE needs to go away.
The least number of them use it voluntarily. It's usually in bigger corporations where it's set as default browser and even if you have an option of installing a different browser, there's no way of getting into the intranet with that.
Very much so. I've worked with major corporations that are still standardized on IE9. Meaning, every employee's computer has IE9 on it. IE6 is still used by a lot of companies simply because they have too much ActiveX code they don't want to migrate.
I know of hospitals that a few years back were requiring IE 6 for their physician portal - long after that version was EOL. I think some are still using those older versions, but now they're doing it the safe way - running it as a remote application connected to via Citrix and hosted on a dedicated system.
It's still jarring to see an old IE version icon on a task bar though.
After over twenty years of the abomination that is browsers produced by Microsoft, I'm ready to beg them to stop making a browser. EVERY. SINGLE. TIME. they release a new version or new name of their browser, they say, "But this time its going to blow the other guys out of the water in terms of speed, security, and standards compliance!" And EVERY. SINGLE. TIME. they drop the ball in significant ways.
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.