3

I have a Windows Desktop application that is written in C++/MFC/COM technologies. This application relies heavily on CHTMLEditView (MSHTML Editing platform) and extensively uses IHTMLxxx COM interfaces.

It seems to be working fine on Windows 10 right now, but I want to know if MS will switch to EdgeHTML anytime soon. If that happens, will IHTMLxxx interfaces stop working with EdgeHTML?

user4617883
  • 1,277
  • 1
  • 11
  • 21

1 Answers1

3

I am not an official MS representative. But I may have some helpful insight.

Edge is a Universal Window App. As far as I know, this makes it generally inaccessible from COM, or even managed code (.NET). Consequently, you won't be able to use COM interfaces to interact with the underlying rendering engine (might be WebKit? I'm not sure).

On the other hand, IE uses the Trident rendering engine, which is completely built with COM. Trident is an integral part of the OS, so I really doubt it will go away anytime soon. It's used for so many UI parts (including Windows Explorer) that I don't think Microsoft will have a compelling reason to obsolete it, at least not for a long, long time.

And, there isn't really a good interoperability story at the level of COM for working with Edge. Universal Apps interoperate via contracts, and to some degree, URL protocol handlers, command line arguments, and other "safer" ways of isolating the app. I suspect that it won't be long before actual containerization technology is used for UWAs.

So, no, I wouldn't hold my breath on IHtmlXXX being implemented using EdgeHTML in any timeframe that could be useful for you. Stick with Trident. While Microsoft will probably make sure Edge has the very, very latest in web standards compliance, I don't think they will let IE languish so far behind that you find it unusable.

Alan McBee
  • 4,202
  • 3
  • 33
  • 38
  • True, except WebKit. Edge was implemented from scratch by MS and it does not use any 3rd party libraries like WebKit. – Andrew Komiagin Dec 17 '15 at 08:57
  • Well, then I think MS wants browser sniffer code to believe that it's like WebKit (because the UA string contains "AppleWebKit"). But what you said sounds like what I kind of remember hearing. – Alan McBee Dec 17 '15 at 11:16
  • 1
    The Windows Runtime is built on top of the Win32 API and COM. Windows Runtime components can be used from desktop applications (both native and managed) without restrictions (see [Windows Runtime C++ reference](https://msdn.microsoft.com/en-us/library/br224617.aspx), for example). Since COM is based on **interfaces**, there is no technical limitation that would inhibit exposing Edge's functionality through the same interfaces. I doubt, though, that there are any plans to implement this. It is, however, technically possible, and your rationale based on presumed impossibility is flawed. – IInspectable Dec 17 '15 at 11:52
  • @IInspectable If it is technically possible, then a technical method for doing it *now* exists. It doesn't, it's just theoretically possible. However, UWP and WRT apps are sandboxed. There is no provision for progids, clsids, typelibs, to be registered and activated within a UWP app from an external caller. There is no provision for providing IPC calls at all, in fact, except where it is initiated within the UWP, or is performed through contracts. It doesn't matter whether the internal workings of WRT/UWP uses IUnknown vtables or not; you can't reach them from outside the sandbox. – Alan McBee Dec 17 '15 at 20:36
  • When you load a UWP component into a desktop application, there is no sandboxing involved. You can freely use any UWP component in a desktop application. After all, it's just COM with embedded metadata (and the Runtime Object activator doesn't need ProgIds or TypeLibs). What you are describing is the barrier between Desktop and Windows Store applications. Those types of **processes** are shielded against each other by the OS. This does not inhibit use of the same UWP **components** in either. – IInspectable Dec 17 '15 at 20:44
  • Also, you seem to be using UWP and WRT interchangeably, while they are very different things. UWP is a platform, that allows to run processes, in a sandboxed environment. WRT, on the other hand, is just a new interface to access OS services. While WRT has provisioning to allow the OS to verify, that components stay within the restrictions imposed by the UWP, WRT components are available to any application. – IInspectable Dec 17 '15 at 20:49
  • You can expose a UWP component as an out-of-proc server, but it's not the same as an inproc server like Trident (mshtml.dll) to use as a rendering engine. So "available to any application" is technically true but very unlikely to be appropriate for the OP to use. You cannot just reference a WRT component in an unmanaged app and navigate and manipulate it like you would a DLL or COM object. If I'm wrong, please link to an example or documentation that demonstrates unmanaged invocation and use of a WRT component from unmanaged code as though it were inproc (like mshtml.dll works). – Alan McBee Dec 17 '15 at 22:36
  • See [How to: Activate and Use a Windows Runtime Component Using WRL](https://msdn.microsoft.com/en-us/library/hh973459.aspx). Scroll down to the bottom to see the entire sample code. Observe that it is a native application (entry point is `int wmain()`). WinRT Components provide .winmd files containing the required metadata to reference and activate WinRT types. The WinRT Component binary is mapped into the native process. There is no out-of-context surrogate process involved. – IInspectable Dec 20 '15 at 18:07
  • Cool. I can be wrong. So all that is missing now are the Edge WRT components. Best bet is they are on one of these two DLLs: `EMODEL.DLL` (probably) or `ESHIMS.DLL`, based on depends.exe. – Alan McBee Dec 20 '15 at 21:15
  • I'm not finding any .winmd files. Unless they are embedded as a resource in another file, or have been packaged (CAB or ZIP), you still won't be able to activate and use the Edge WRT components. Still technically not possible; only theoretically possible. – Alan McBee Dec 20 '15 at 21:30
  • You don't need .winmd files to activate WRT types. .winmd files allow the compiler to generate activation code for you. It is technically possible to activate a WRT type without the compiler doing all the groundwork for you. All you really need are the binary's exports of the class factories, available through the export table. This may be impractical, but it is technically doable, not just some theory. – IInspectable Dec 28 '15 at 19:22