Ruby

Yes, the behavior of OleInitialize is generally additive and per the docs at https://msdn.microsoft.com/en-us/library/windows/desktop/ms690134(v=vs.85).aspx, it is necessary to call before using any COM functions that use:

• Clipboard
• Drag and Drop
• Object linking and embedding (OLE)
• In-place activation

Under the hood, OleIntialize calls CoInitializeEx with COINIT_APARTMENTTHREADED, but that value is unsupported on Nano. See the COINIT enumeration docs for more details at https://msdn.microsoft.com/en-us/library/windows/desktop/ms678505(v=vs.85).aspx

I think the main point here is that calling OleInitialize will never work on Nano Server, since Nano only supports COINIT_MULTITHREADED, which OleInitialize cannot specify. Nano does support COM, but not all of the functionality that Ruby might normally enable on other platforms by calling OleInitialize. It's better in this case to have a degraded experience on Nano that still allows WIN32OLE to work / interact with COM objects, even if it doesn't support OleInitialize. Also note that WIN32OLE.connect will not work since Nano does not support COM monikers.

In my tests OleInitialize(NULL) succeeded on Nano Server TP5 and reverse forwarders installed. Then it already is basically equivalent to CoInitializeEx(NULL, COINIT_MULTITHREADED) (everything else it does is printing two debugging messages). Does it fail for you?

In Window Nano Server TP5, Microsoft has temporarily changed the behavior of OleInitialize internally to use CoInitializeEx(NULL, COINIT_MULTITHREADED) as a compatibility fix, despite what the spec / documentation says. It is understood that this will not be the final shipping behavior. I have no information on the timeline, but you can see some more notes at https://github.com/puppetlabs/facter/pull/1327/files#diff-6c0a571515f6f937e35e5b86cbeb8821R11

Masaki - have you had a chance to look at this? The Nano Server RTM is due out soon, and it will fail when OleInitialize is called.

At that point, the Ruby WIN32OLE support will cease to work on Nano.

Anything that can be done to address that prior to it failing in the wild would be great.

Thanks!

Ethan, It's not easy for me to use CoInitializeEx instead of OleInitialize.
I had tried to use CoInitializeEx(NULL, MULTITHREADED) before, but I encountered SEGV about thread issue
and could not fix it.
To make Ruby's thread and win32ole's thread work well, I use OleInitialize and CoRegisterMessagefilter.
Unfortunately, CoRegisterMessagefilter works with OleInitialize.
I'll try to investigate this issue again, but I'm not sure to fix it.
Do you have any good idea to fix this issue?

Masaki -

I apologize for missing your response. There is a pull request open at https://github.com/ruby/ruby/pull/1423 from one of the engineers at Chef addressing this issue. If you could review, that would be great.

Thanks!