With the upcoming release of Puppet 3.7, we're introducing a Ruby x64 based installer for Windows. In addition, this x64 installer is based on Ruby 2.0.0, which is also an entirely new Ruby version for Puppet on Windows. Note that for the sake of a more measured roll-out of Ruby 2, we will continue to ship Ruby 1.9.3 with the Puppet 3.7 x86 installer. We intend to ship Ruby 2.0.0 (or newer) in a future version of our x86 installer.
x64 support on Windows represents a significant engineering effort that involved many moving parts, not limited to: * updates to 3rd party gems * heavy refactoring and removal of old code / mixins from existing classes * making all native Windows API calls through FFI * updates to Facter * changes to our build, testing and delivery pipelines * maintaining compatibility with all currently supported Windows platforms * updates to affected Windows modules The scope of this work is captured in an epic within JIRA: https://tickets.puppetlabs.com/browse/PUP-2396 As part of the broad sweeping changes across our Windows specific code, there were a number of changes introduced that are breaking to the downstream consumers of the Puppet code, which should be limited to module authors. Modules Impacted ==================== We have identified and fixed code issues in affected Windows modules that Puppet publishes. These modules required updating not just to support x64, but also 3.7 based on internal API changes. The expectation is that we will be publishing updates to these affected modules shortly, prior to the 3.7 release: * DISM - 1.0.0 was released on 8/13/2014 with 3.7 and x64 support * ACL - code is under review, merge anticipated shortly * Registry - code has been merged, undergoing testing, release pending * Reboot - code has been merged, undergoing testing, release pending Furthermore, we scanned all of the existing module code published to the forge in an effort to notify module authors of these upcoming changes. These authors have been notified about specific issues that they should address to maintain backward compatibility with 3.6, and ensure compatibility going forward with future Puppet releases. The 4 modules that we identified as impacted are: * badgerious/npackd - author has acknowledged upcoming changes * badgerious/windows-env - author has acknowledged upcoming changes * basti1302/windows_path * ptierno/windowspagefile - author has published 1.1.0 on 8/12/2014 per our recommendations However, since not all modules are published to the forge, we wanted to ensure those maintaining their own internal module code are aware of how they are to be impacted. Breaking Code Changes ==================== In a number of places we were able to add deprecation warnings when we consciously relocated internal methods from one class to another for the sake of organization. In some cases this was impractical due to methods removed that were previously available via mixin. We are presently forwarding old method calls where it made sense, but these backward compatible methods / deprecation messages will be removed in Puppet 4. In greater detail, the following are the most important breaking changes to be aware of: * The sys-admin gem has been removed, so calls to the Admin class are no longer valid. * The win32-taskscheduler gem has been completely removed in favor of including an internal FFI compatible implementation of the Windows v1 COM taskscheduler API. Backwards compatibility should be maintained, though the file location has moved and thus should be referenced via require 'puppet/util/windows/taskscheduler' * The windows-pr, windows-api and win32-api gems have all been removed. They all contained Win32 API definitions that were not x64 compatible. - Most classes that were included with a require 'windows/xxxxx' are no longer possible to include, but similar functionality should be maintained in classes within the Puppet::Util::Windows namespace. When in doubt, feel free to respond to this email or otherwise ask the list. - Constants within the Windows:: namespace are no longer available. Many of the same constants are available within the Puppet::Util::Windows namespaced classes that uses them - Puppet::Util::Windows::User no longer mixes in windows-pr class Windows::Security - Puppet::Util::Windows::Error no longer mixes in windows-pr class Windows::Error - Puppet::Util::Windows::Process no longer mixes in windows-pr class Windows::Process, Windows::Handle or Windows::Synchronize - Puppet::Util::Windows::Security no longer mixes in windows-pr classes Windows::File, Windows::Handle, Windows::Security, Windows::Process, Windows::Memory, Windows::MSVCRT::Buffer or Windows::Volume - Puppet::Util::Windows::SID no longer mixes in windows-pr classes Windows::Security or Windows::Memory - Windows::Error constants may have moved - for instance, ERROR_FILE_NOT_FOUND is now found within Puppet::Util::Windows::Error - The WideString class no longer exists, but similar functionality is present in Puppet::Util::Windows::String.wide_string and through an extension we've made to FFI, as FFI::Pointer.from_string_to_wide_string - Generally calls that show up as API:: or API.new are no longer valid and should be replaced with FFI equivalent definitions * win32-dir, win32-eventlog, win32-process, win32-security and win32-service gems have all been updated to newer FFI compatible versions. In some cases, these gems have made API changes and have moved constants to new locations. For constants, it's suggested to locally namespace them and define them in your own module where practical to do so. * ADSI class has moved from Puppet::Util::ADSI to Puppet::Util::Windows::ADSI and the new file location can be referenced with require 'puppet/util/windows/adsi' * Methods name_to_sid, name_to_sid_object, octet_string_to_sid_object, sid_to_name, sid_ptr_to_string, string_to_sid_ptr, valid_sid? have been moved from Puppet::Util::Windows::Security to Puppet::Util::Windows::SID https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/windows/security.rb#L669-L703 * Method get_file_attributes of Puppet::Util::Windows::File has been renamed to get_attributes * Methods get_attributes and add_attributes of Puppet::Util::Windows::Security have been moved to the Puppet::Util::Windows::File class Additional Considerations ==================== There are a few additional things to be aware of to make sure your module behaves correctly in an x64 environment: * When using ENV['ProgramFiles'] note that it will resolve differently on an x64 Windows depending on whether the process is 32-bit or 64-bit. On 32-bit, it resolves to C:\Program Files (x86)\ whereas in 64-bit, it will resolve to C:\Program Files\ - The PowerShell module resolves executables in a 64-bit / 32-bit friendly way - see https://github.com/puppetlabs/puppetlabs-powershell/blob/master/lib/puppet/provider/exec/powershell.rb#L6-L13 * Should you need to make Win32 API calls, always use FFI and never the Win32API class. * There are plenty of examples in the Puppet code to look at. Further, the code include helpers around FFI usage, including dealing with properly freeing native memory that must have LocalFree or CoTaskMemFree against it - see https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/windows/api_types.rb * FFI can be relied on as being a part of Puppet as far back as 3.3.0 (PE 3.1.0), though the helpers above are not . Please take this into consideration if it's necessary to make native Win32 calls, and when expressing your module compatibility. * Ruby's Win32OLE class continues to be safe to use for IDispatch based COM objects. The file com.rb added support for interoperating with IUnknown based COM objects as part of this release, though this is an advanced topic. Please look to alternatives if you intend to use a module that is not late-bound / script friendly (i.e. based on IDispatch). We apologize that weren't able to disseminate this information to module authors sooner; please don't hesitate to ask if there are any questions. We want to make the 3.6 to 3.7 upgrade as smooth as possible. Thanks! -- -- Ethan Brown et...@puppetlabs.com Senior Software Engineer Join us at PuppetConf 2014, September 20-24 in San Francisco Register by September 8th to take advantage of the Final Countdown —save $149! -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALCHMcSs_S5PeoxT_D_N2J_zpSho5LavMwx6Lz9cfcyv1epQ3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
