Integrating closed-source DLL/SO with Micro-Manager plugin?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Integrating closed-source DLL/SO with Micro-Manager plugin?

Graham Bartlett
Hi all,

I'm the lead software engineer in Queensgate.  We've just been acquired by Prior Scientific Instruments, and one of the things we're looking at is getting support for our controllers/stages rolled into Micro-Manager.  In part this is self-interest (because Prior use Micro-Manager internally), but we'd like to get this out to customers as well.

We have a cross-platform DLL already which provides application interfacing on Windows and Linux (via RS-232, USB emulated serial, or Ethernet coming soon).  Unfortunately this DLL is closed-source at the moment, because we have a common DLL for all our commands including internal configuration stuff.  We can support pretty much any Linux platform that customers want to use, but it goes out as 32-bit and 64-bit SOs.  It's not ideal, but at the moment it is what it is.

I've seen your policy about generally only accepting open-source device adapters.  I have no problems with setting up an open-source device adapter, but it would only be a wrapper around the closed-source DLL, and this feels like I wouldn't be following the spirit of the law.  Equally though I've seen references to using "/3rdparty" for, quote, " optional proprietary libraries that may be required for our hardware".  Does this need the user to drop the DLL/SO into the right directory themselves, or is it something I need to provide if I submit a device adapter for inclusion?

Best regards,

Graham Bartlett.


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete this e-mail. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Integrating closed-source DLL/SO with Micro-Manager plugin?

Stuurman, Nico
Hi Graham,


> I'm the lead software engineer in Queensgate.  We've just been acquired by Prior Scientific Instruments, and one of the things we're looking at is getting support for our controllers/stages rolled into Micro-Manager.  In part this is self-interest (because Prior use Micro-Manager internally), but we'd like to get this out to customers as well.

Great to hear!

> We have a cross-platform DLL already which provides application interfacing on Windows and Linux (via RS-232, USB emulated serial, or Ethernet coming soon).  Unfortunately this DLL is closed-source at the moment, because we have a common DLL for all our commands including internal configuration stuff.  We can support pretty much any Linux platform that customers want to use, but it goes out as 32-bit and 64-bit SOs.  It's not ideal, but at the moment it is what it is.
>
> I've seen your policy about generally only accepting open-source device adapters.  I have no problems with setting up an open-source device adapter, but it would only be a wrapper around the closed-source DLL, and this feels like I wouldn't be following the spirit of the law.  Equally though I've seen references to using "/3rdparty" for, quote, " optional proprietary libraries that may be required for our hardware".  Does this need the user to drop the DLL/SO into the right directory themselves, or is it something I need to provide if I submit a device adapter for inclusion?

I am not exactly sure what the policies of Open Imaging are in this
respect, but in the past, it was not uncommon to have proprietary
libraries/drivers that interface with the Micro-Manager device adapter. 
When the device comes with a system-level driver, then it is of course
quite obvious that the driver needs to be provided by the company
itself.  When there is an interface layer that streamlines communication
with the driver or the device itself, then this can either be provided
by the company, or it can be included in the Micro-Manager binary
distribution (whether or not the latter is desirable depends a bit on
the size of the library and how widely it will be used, i.e. the trade
off between increased size of the installer and ease of use for the
users).  Although we do love to see everything Open Source, we have in
the past certainly not shunned away from closed source API, as long as
the device adapter itself is Open and its source available.

There are a couple more issues though:
- To build such device adapters, Micro-Manager needs access to the
header files, and other things needed to build the code (most often .lib
files on Windows).  There are version issue with this, as well as issues
with the compilers used for C++ code, which is an important reason to
stick to C only for the library interface.  The headers and other files
needed to build can be made publicly available through our
3rdpartypublic repository, or can be kept closed source if so desired by
the company (in which case it goes into the 3rparty repository).
- Micro-Manager provides its own interface to RS-232 serial ports (as
well as HID devices, some user-space USB devices, and ethernet).  I
think that it is desirable for the user to stick to that concept, as it
makes managing ports and hardware much easier for the user.  If your
library handles that communication itself you may not want to do so, at
the cost of more complexity for the end user.  If the device uses a
straight forward interface, it could be more interesting to not use your
own closed-source DLL at all, but simply port the relevant parts into a
Micro-Manager device adapter.


Hope this helps!


Best,


Nico
-




_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Integrating closed-source DLL/SO with Micro-Manager plugin?

Graham Bartlett
> When there is an interface layer that streamlines communication with the driver or the device itself, then this can either be provided by the company, or it can be included in the Micro-Manager binary distribution (whether or not the latter is desirable depends a bit on the size of the library and how widely it will be used, i.e. the trade off between increased size of the installer and ease of use for the users).

Considering Queensgate are pretty new at getting back into this area, I wouldn't ask you to increase your release size for a niche product.  I'll put together an open-source device adapter, and just give users instructions for how to copy the DLL/SO.  The DLL API doesn't change and commands are backwardly-compatible, so it should all work pretty easily.

I do have some plans for how we could handle security with some external configuration, at which point the whole interface DLL can become open-source.  We don’t have time for this right now though.

> To build such device adapters, Micro-Manager needs access to the header files.

That's not a problem - the API is stable and the headers are freely available.  Our library includes a C++ adapter class which wraps the DLL with dynamic loading, avoiding the usual problems with DLL static linkage.

> Micro-Manager provides its own interface to RS-232 serial ports (as well as HID devices, some user-space USB devices, and ethernet) .  I think that it is desirable for the user to stick to that concept, as it makes managing ports and hardware much easier for the user.

That sounds sensible.  It seemed like a good idea at the time (most Darwin Awards start with that phrase!) to handle I/O in the DLL.  I have another in-house application though where it would work better to have our library simply as a protocol layer and allow the I/O to be independent; and I've also looked at EPICS drivers which have a similar concept.  Knowing what I know now, it'd make sense for me to update the DLL to fit this I/O model.

Thanks for the feedback, Nico.  It doesn’t sound like we're too far away, but it's great to have this kind of feedback that lets us make our kit better for users.  I'll start getting this rolling, and get back to you when I've got something to submit.

Cheers,

        Graham.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete this e-mail. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general