Project

General

Profile

Bug #12371

Windows Nano Server WIN32OLE compatibility

Added by alexpilotti (Alessandro Pilotti) over 3 years ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Target version:
-
[ruby-core:75460]

Description

The OleInitialize() call used in WIN32OLE is not supported on Nano Server due to the fact that the STA COM model is not available:

https://github.com/ruby/ruby/blob/32674b167bddc0d737c38f84722986b0f228b44b/ext/win32ole/win32ole.c#L820

As an alternative, CoInitializeEx(NULL, COINIT_MULTITHREADED) can be called when running on Nano Server, thus ensuring both compatibility with the preexisting behaviour and support for Nano Server.

History

Updated by nobu (Nobuyoshi Nakada) over 3 years ago

  • Description updated (diff)
  • Status changed from Open to Assigned
  • Assignee set to suke (Masaki Suketa)

Doesn't CoInitialize differ than OleInitialize?

Updated by Iristyle (Ethan Brown) over 3 years ago

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.

Updated by cremno (cremno phobia) over 3 years ago

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?

Updated by Iristyle (Ethan Brown) over 3 years ago

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

Updated by Iristyle (Ethan Brown) over 3 years ago

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!

Updated by suke (Masaki Suketa) over 3 years ago

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?

Updated by Iristyle (Ethan Brown) almost 3 years ago

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!

Updated by jeremyevans0 (Jeremy Evans) about 2 months ago

  • Status changed from Assigned to Closed

This appears to be fixed by 8feb9779182bd4285f3881029fe850dac188c1ac.

Also available in: Atom PDF