I would like to access a COM interface from a WebAssembly module. If possible, this will be my first WebAssembly module. Can it be done? What challenges and/or restrictions might I face when accessing a COM interface from WebAssembly?
WebAssembly is more or less like a virtual machine, one can't communicate directly with any other parts of the system if the needed interfaces aren't implemented or provided for the virtual machine. WebAssembly won't provide such thing for you, thus, you (or some project probably doesn't exist yet) have to do more work to make such thing happen.
Related
From webassembly.org:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.
In the context of Wasm/WASI, what is
a WebAssembly runtime?
a WebAssembly interpreter?
a WebAssembly engine?
and in the above context:
the host environment?
I suppose the practical meaning of these terms can differ when used in a web browser context, but I think focus should be on the native usage of Wasm code.
I must admit, I preferred their previous summary of the technology:
WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web
To be specific WebAssembly is an instruction set, it looks quite like regular assembly language, with a low-level 'feel' to it. The language supports numeric types only, no strings, arrays etc ...
The WebAssembly specification also defines the virtual machine that it runs on.
To answer your questions:
what is a WebAssembly runtime?
It is a machine, or virtual machine that can execute the WebAssembly instruction set, as described by the specification. You have one in your browser!
what is a WebAssembly interpreter?
Interpreters and compilers are two different approaches to executing a language - as described here:
How does an interpreter/compiler work
what is a WebAssembly engine?
Pretty much the same as a runtime.
the host environment?
WebAssembly runtimes typically live within a host - this is because WebAssembly itself cannot perform any I/O. In order to do something useful, it works with the host environment to achieve this.
I have a vb6-mysql client-server desktop application which is distributed as a setup file.
It uses DLL all logical operations as well as database operations. The EXE and the DLL are installed in the server as well as the client machines. When I say server which only means the database resides in that machine no other difference in EXE or DLLs.
As all the database operations are done in the DLL when connected from a client machine, performance would be less. It is not possible now to change all the logic into database.
Is it possible to store the DLL in the server machine only and use the same DLL by the client machine also so that database connection will always be from the server itself?
Is converting the DLL to a windows service the possible solution for this?
How can I to convert it to a service?
And finally, if it is possible to make the DLL act as a service, what would the connection issues be?
You appear to be trying to rediscover n-tier application development.
The usual way this would be done using VB6 within a LAN would be to create an ActiveX EXE instead of a DLL so you can use DCOM. However DCOM isn't something you'd want to expose over the Internet.
For such cases it is more typical to use a commonly-open-port protocol such as HTTP or HTTPS. Almost everyone has firewall settings permitting outbound HTTP and HTTPS connections and most of the major Web servers undergo regular hardening to make them safer to expose to the Internet.
The classic way to do this with VB6 was to use IIS to host the Remote Data Service, which uses a form of Web Service "under the covers" where your program doesn't deal with the gory details. However this is a deprecated approach, and today configuring IIS and the RDS components can be a chore since they are locked down hard by default.
This leaves you with such things as the deprecated SOAP Toolkit or 3rd party tools such as those in the PocketSOAP suite... or you can roll your own.
Doing this from scratch can be a bit of work but is more flexible, allowing REST instead of SOAP which can have advantages in itself. You could use whatever Web server you choose that can work with VB6 (via CGI, etc.).
The hardest approach to justify might seem the simplest on the surface: create your own protocol over TCP and write a Windows Service. This can be the most flexible of all but it can be more work than other options and you are on your own as far as making it and keeping it secure. You'll probably also face firewall issues depending on where your clients are and what the local firewall policies are there.
When we could rely on DCOM the issues were relatively small aside from security configuration headaches. With the Internet in the picture it is an entirely different story.
This really isn't something you undertake casually. Even assuming that your database is safe exposed to the Internet is naive and should be rethought.
Im required to write a Silverlight application using WCF.
I'm also required to use Dependency Injection to gain access to this service in another library.
(I add a Silverlight enabled WCF Service)
The problem is in trying to use Dependency Injection (Prism/MEF in this case). When I make a Silverlight Shared library that will have interfaces for this service, I cannot add this library in the ASP.Net project due to the fact that it is Silverlight library. If I make a non-Silverlight library I cannot add that library to other projects to share that common interface.
Basically I need a library I think to share between projects in Silverlight so I can do this service injection.
Any information is appreciated
As slugster said - this done via linking to windows library files from silverlight library.
You do it as described here: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
I just wanted to add.. Since you go there - what you need is another Framework/Technology. Usually those classes you talking about depend on other classes/namespaces that live in windows only or silverlight only world. And then you need to transfer object data via wire.
Microsoft's solution to this - RIA Services. What it does - it takes your Windows classes and generates proxy classes on Silverlight side. Kind of what you need. And it works with WCF services.
There is 3rd party solutions like CSLA and DevForce.
I use DevForce and it does many things automatically, but instead of generating proxy classes - it creates links just like what you want.
Whether you realise it or not, your question is a duplicate of this one: Shared data object between WCF service and Silverlight app While not asked the same way, the answer is the same.
You need to create a separate project, and share the code files (as links) from one project to the other. Your problem is that the Silverlight project is compiled for a different runtime to the ASP.NET/WCF project. Because they cannot reference a common library, linking the shared files as mentioned is the easiest way to share code between the two projects targetting different runtimes.
I implemented an out-of-proc COM server (implemented in a Service). I don't want other applications to access all the functionality in the COM server, so I developed an in-proc server (DLL) which would talk to the out-of-proc server.
Because I don't want the interfaces in the out-of-proc COM server to be accessed directly, I don't embed the type library with the Service so I thought I could use #import and have access to the COM server through the TLB. However, when I try in my in-proc-server to create an instance of a class implemented in the service, I get an E_NOINTERFACE back. I guess this is due to marshalling, but I couldn't figure out how to overcome this.
Any idea on how to communicate from the in-proc-server with my out-of-proc server without exposing the interface details of the out-of-proc server?
I'm not sure about how this will help to conseal the interfaces, but there're three ways to make marshalling working and typelib is one of them. The other quite easy way is a proxy/stub - a bunch of code in a separate in-proc COM server that will automagically do the marshalling once it has been registered in Windows registry. Again, I'm not sure how this will help conseal the interface, but it looks more covert then a type library that just exposes teh interface to anyone with OLEView.
I need to create a service. I know that you can do it with just a console application but it can also be done with ATL.. What are the benefits of the ATL Service vs a simple console application service? I understand that ATL is COM.. but what are the benefits of COM with the service.. thanks!
The service doesn't exactly benefit from COM, but rather the other way around.
By hosting your COM objects in a service, you get all the system features of services (startup before users log on, controlled policies watchdog, configuration of identity, etc.)
ATL gives you the opportunity to run your COM objects in a service context, as opposed to in-process (DLL) or regular out-of-process hosting. COM+ is another alternative for customized hosting.
If your service is just a background service, adding COM support could give you simple programmability, but otherwise I don't see any benefits.
So, I'm not sure that answers your question... The question feels backward :)