I have a 3rd party COM component that won't work on Windows 8 but will work perfectly fine if run in Windows 7 compatibility mode on Windows 8. However, I don't want the software to run in compatibility mode, just the COM component. Is it possible?
BTW, it's not possible to get a newer/working version of the COM component.
Thanks
Compatibility mode applies to a whole process at a time. The only way to do what you ask for is to run the COM object in a different container process, either using DCOM (if the COM object's interfaces have the necessary stubs and proxies registered for use as an out-of-process object) or by writing your own remoting layer.
Related
I have a C# 32-bit COM DLL that talks to a C# 64-bit exe using the 'DllSurrogate' method described in Hosting a .NET DLL as an Out-Of-Process COM Server (EXE).
I need this setup because the 32 bit C# talks to a legacy 32-bit C++ dll.
I thought everything was working fine, but I have just realised that when you create a second instance of the 64-bit exe you do not get a second "DLL Host" (COM Surrogate) process. This is no good for my application.
This is a Windows Desktop application and I need to know that if the user starts it multiple times they all run in their own separate processes. Otherwise, data in the legacy dll might be corrupted and they will certainly run into the 32-bit process memory limitation.
The surrogate is registered using the AppId DllSurrogate key.
The 32-bit class instance is created in the 64-bit exe by a call to CoCreateInstance.
From some Googling it seems that the solution to my problem should involve the REGCLS_SINGLEUSE key from the REGCLS Enumeration. However, I can't see where to supply that key. Also, I note that in this enumeration there is a separate REGCLS_SURROGATE key. I hope that doesn't mean that DLL Surrogate and Single Use are mutually exclusive!
Any ideas would be welcome.
We have an requirement to integrate our WPF application and Windows Store app with some very old COM technology.
It requires us hosting a 3rd party web site in a browser control. That page does a GetObject call in VBScript to find a COM component that we will have had to add to the RunningObjectTable (ROT).
The 3rd party web site cannot be changed any time soon. This works currently in old VC++ app.
I am currently having and issue with the WPF app but will deal with that in a separate question.
I am guessing what we are considering doing is not going to work in a Windows Store app. I was hoping someone can confirm what I believe
The WebView control in Windows Store will not support VBScript running within it
A Windows Store app cannot target a .NET Framework dll (*Rather that NETCore) that is a wrapper around a COM interface
A store app would be using the EdgeHTML engine to host web pages, which has no VBScript support.
A store app would be using the appcontainer integrity level ROT, which is different than the medium integrity level ROT accessible from your old VC++ app (forget .Net wrapper of COM server if the COM server itself won't work).
I will refer applications in Windows Store for either Windows 8/8.1 or Windows 10 as UWP applications as Wikipedia does, if I do not mistake it. Windows RT(not WinRT though) is not discussed to avoid confusion.
I wonder what API's no matter public or undocumented that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on, so that they cannot be port to Windows 7, which is NT 6 as Windows 8/8.1/10 do.
If nothing much are there, but only due to M$'s market strategy to promote new technology'd Metro, there might have been some 3rd-party runtime/framework for Windows 7 on which Windows Store will work and UWP applications can run, which will surely spend no more effort and cause no more legal or compatibility trouble than Mono or Wine.
Edit: As How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? says, it's a layer quite similar to .NET that lies between COM and application, if I didn't misread.
It's not a marketing strategy by the evil M$, and writing things like that makes you look rather juvenile. There's a giant layer of code (arguably an entire operating system within an operating system) that was written to enable Metro/Modern/UWP apps to run in Windows 8, tweaked in 8.1, and further refined in 10. That layer simply isn't there in Windows 7, wasn't backported, isn't going to be backported, and can't reasonably be backported by a third party who lacks access to the undocumented details of the implementation.
There is no conspiracy afoot here. It is a simple matter of new operating systems supporting things that old operating systems don't. The new features that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on is the entire notion of a Windows Store and a UWP application.
The version number ("NT 6", as you point out) doesn't matter. All that tells you is they didn't massively rewrite the kernel. You don't have to rewrite the kernel in order to write a new layer on top of it.
If you want to run Metro/Modern/UWP/Store applications, you need to update to a later version of Windows. Alternatively, you can just write a regular Win32 application, which will run on all versions of Windows, including the latest builds of Windows 10.
I am currently writing a Win 10 UWP project that provides administrative control for a windows service. I was unable to reference a standard class library that contains my model layer. This Model layer hold objects that I want to share with another project that is a Windows Service project. What is the best way to do this and can I create a UWP app as a standard long running Windows Service? Would I be better off porting the Windows Service to a WCF project and can a WCF run as a Windows Service? I'm confused with the new server offerings for Win 10 and Win Server 2016. The Windows Services that I wrote use custom protocols based on serialized objects with a binary serializer. Apparently that has changed as well with the new windows sockets models which seem to require that objects are serialized into a string. I'm very confused by all the recent changes and lack of Microsoft documentation. The only proper books that I found on Amazon are all for pre-order for the middle of next year.
Solved my own problem. The trick is to upgrade the Windows Service and it's layer projects from the 4.5.2 build to 4.6 and then use a portable class project for my model layer. Switching out Binary Serialization to JsonConvert and bang it works.
I would like to mimic the behaviour of a VB6-Active-X-Exe.
To do that, I have created a new project and set its settings to "COM Visible=True".
I can now add this .exe to my main application, and I can call it, call functions in that .exe, etc.
However, it is not really out of process, I think.
I would therefore like to investigate more about such an .exe's behaviour.
But I did not find any official documentation on it.
Can somebody tell me where to find more info?
Thank you!
Out-of-process COM servers (ActiveX EXE's) are not as easy to create with VB.NET as they were with VB6. When you reference a .NET executable (as a .NET assembly reference, not as a COM reference) from another .NET project, it always treats it as in in-process library. The .NET Framework has no direct equivalent to COM's out-of-process servers. Typically, in such scenarios, it is recommended that you create a WCF service, a web service, or use .NET remoting. WCF services are preferred since they use the most modern technology of the three.
However, since .NET supports COM interoperability, it is technically possible to create a .NET executable which can be registered as a out-of-process COM server. Then, when another .NET project references it via COM (rather than as a .NET assembly reference) it will run out-of-process. Microsoft provides an example of how to do that here.
However, if you don't need it to be COM (so that it can be used by non-.NET applications), I would recommend that you go the pure .NET WCF service route.