5 ms·

> 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

> 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.

chrismorgan 8y ago
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-chromium-as-a-library 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.)
- kodablah 8y ago
  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 https://github.com/zserge/webview to watch Electron adoption decrease or even an API-compat version using shared libs already on the system.
  - cptskippy 8y ago
    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.
    - userbinator 8y ago
      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.
      - cptskippy 8y ago
        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.
        userbinator 8y ago
        For example, .NET framework calls into Win32 CreateFile when opening a file: https://referencesource.microsoft.com/#mscorlib/microsoft/win32/win32native.cs,a049b9ef1a4c580d 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.wikipedia.org/wiki/Architecture_of_Windows_NT https://en.wikibooks.org/wiki/X86_Disassembly/Microsoft_Windows https://en.wikibooks.org/wiki/X86_Disassembly/Microsoft_Wind...
- ngold 8y ago
  So are you pro or anti open source? It seems both have their challenges. But only one can be addressed by outsiders.
  - pjc50 8y ago
    This isn't all that relevant on Windows.
    - microcolonel 8y ago
      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.
poizan42 8y ago
Here you go: https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/xaml-host-controls https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/x...
- kodablah 8y ago
  I saw this as part of https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/index 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.
  - mastax 8y ago
    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.
    - poizan42 8y ago
      There's this: Walkthrough: Hosting WPF Content in Win32[0] 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/advanced/walkthrough-hosting-wpf-content-in-win32 https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc...
      - mastax 8y ago
        WPF ≠ UWP XAML, which is what the EdgeHTML control is.
        poizan42 8y ago
        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.
bartread 8y ago
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.
- jnxx 8y ago
  Modern computers have about five times more latency as an Apple IIe: https://danluu.com/input-lag/ https://danluu.com/input-lag/
- setquk 8y ago
  They just did this. Latest release is actually usable as of the April 2018 windows 10 build (1803). Was quite surprised.
  - bartread 8y ago
    Thanks - will give it another go! Would be amazing to have that work properly since, otherwise, Edge performs and works well.
    - setquk 8y ago
      Yep. I’ve decided to give it a try for a couple of weeks. I think I lasted a day on the last release before quitting. The new one also has reasonably sized UI elements ie smaller.
- pcf 8y ago
  As a Mac user – how on earth could MS have a keyboard latency for so long? Seems very unprofessional.
  - bartread 8y ago
    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.
setquk 8y ago
Literally announced 4 days ago. https://blogs.windows.com/msedgedev/2018/05/09/modern-webview-winforms-wpf-apps/ https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie...
- kodablah 8y ago
  Looking for a dead simple cpp example if anyone knows of one.
hb3b 8y ago
And allow it to be installed on Server for purposes of RDS.
userbinator 8y ago
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.
pjc50 8y ago
Edge has a number of deficiencies (font rendering, failure to take tabs seriously) that make it unsatisfactory.

chrismorgan 8y ago

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-chromium-as-a-library 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.)

kodablah 8y ago
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 https://github.com/zserge/webview to watch Electron adoption decrease or even an API-compat version using shared libs already on the system.
- cptskippy 8y ago
  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.
  - userbinator 8y ago
    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.
    - cptskippy 8y ago
      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.
      - userbinator 8y ago
        For example, .NET framework calls into Win32 CreateFile when opening a file: https://referencesource.microsoft.com/#mscorlib/microsoft/win32/win32native.cs,a049b9ef1a4c580d 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.wikipedia.org/wiki/Architecture_of_Windows_NT https://en.wikibooks.org/wiki/X86_Disassembly/Microsoft_Windows https://en.wikibooks.org/wiki/X86_Disassembly/Microsoft_Wind...
ngold 8y ago
So are you pro or anti open source? It seems both have their challenges. But only one can be addressed by outsiders.
- pjc50 8y ago
  This isn't all that relevant on Windows.
  - microcolonel 8y ago
    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.

poizan42 8y ago

Here you go: https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/xaml-host-controls https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/x...

kodablah 8y ago
I saw this as part of https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/index 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.
- mastax 8y ago
  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.
  - poizan42 8y ago
    There's this: Walkthrough: Hosting WPF Content in Win32[0] 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/advanced/walkthrough-hosting-wpf-content-in-win32 https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc...
    - mastax 8y ago
      WPF ≠ UWP XAML, which is what the EdgeHTML control is.
      - poizan42 8y ago
        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.

bartread 8y ago

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.

jnxx 8y ago
Modern computers have about five times more latency as an Apple IIe: https://danluu.com/input-lag/ https://danluu.com/input-lag/
setquk 8y ago
They just did this. Latest release is actually usable as of the April 2018 windows 10 build (1803). Was quite surprised.
- bartread 8y ago
  Thanks - will give it another go! Would be amazing to have that work properly since, otherwise, Edge performs and works well.
  - setquk 8y ago
    Yep. I’ve decided to give it a try for a couple of weeks. I think I lasted a day on the last release before quitting. The new one also has reasonably sized UI elements ie smaller.
pcf 8y ago
As a Mac user – how on earth could MS have a keyboard latency for so long? Seems very unprofessional.
- bartread 8y ago
  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.

setquk 8y ago

Literally announced 4 days ago. https://blogs.windows.com/msedgedev/2018/05/09/modern-webview-winforms-wpf-apps/ https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie...

kodablah 8y ago
Looking for a dead simple cpp example if anyone knows of one.

hb3b 8y ago

And allow it to be installed on Server for purposes of RDS.

userbinator 8y ago

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.

pjc50 8y ago

Edge has a number of deficiencies (font rendering, failure to take tabs seriously) that make it unsatisfactory.