Thursday, January 24, 2019

PuTTY++ 9.2 has been released

WinOnMacs released Putty++ 9.2 for Microsoft Windows today.

About PuTTY++

PuTTY++ is a telnet and SSH client for Windows and UNIX. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.

The cost of Putty 9.2 is only $15.00. Anyone who has purchased Putty in the past three months is entitled to a free upgrade. Putty comes with three months of upgrades and of course a 14-day money back guarantee.

Supported Protocols:
  • Telnet
  • FTP
  • SFTP
  • SSH
  • SCP
Version 9.2 New Features:
  • Minor bug fixes
We now use FastSpring as our preferred storefront, you can pay with Credit / Debit Cards, PayPal, Amazon payments, Wire Transfer etc. etc. This store is very secure, simple and fast.

Tel-FTP 2.2 for macOS High Sierra and Mojave has been released

WinOnMacs released Telnet FTP 2.2.0 for MacOS High Sierra and Mojave today.

About FTP

The File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network.

FTP is built on a client-server model architecture and uses separate control and data connections between the client and the server. FTP users may authenticate themselves with a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it.

About Telnet

Telnet is a protocol used on the Internet or local area networks to provide a bidirectional interactive text-oriented communication facility using a virtual terminal connection. User data is interspersed in-band with Telnet control information in an 8-bit byte oriented data connection over the Transmission Control Protocol (TCP).

Supported Protocols :
  • Telnet
  • FTP
About WinOnMacs :

There is a multitude of software developed only for the Windows operating system and even when software vendors port their applications to another platform, generally it lacks features that the Windows version contains. The only solution these developers face is to have access to both systems for testing which leads to increased infrastructure demands, and wasted project resources. Our goal is to have native ports of essential Windows tools and applications made available for MacOS users.

Version 2.2.0 New Features :
  • minor bug fixes
We now use FastSpring as our preferred storefront, you can pay with Credit / Debit Cards, PayPal, Amazon payments, Wire Transfer etc. etc. This store is very secure, simple and fast.

Wine stable release 4.0 is now available for Linux FreeBSD Android and macOS

Wine stable release 4.0 is now available for Linux FreeBSD Android and macOS

The Wine team is proud to announce that the stable release Wine 4.0 is now available.
This release represents a year of development effort and over 6,000 individual changes. It contains a large number of improvements that are listed in the release notes below. The main highlights are:
  • Vulkan support.
  • Direct3D 12 support.
  • Game controllers support.
  • High-DPI support on Android.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.

What's new in Wine 4.0

*** Direct3D

- Initial support for Direct3D 12 is implemented. Direct3D 12 support
  requires the vkd3d library, and a Vulkan-capable graphics card.

- The Multi-Threaded Command Stream feature is enabled by default.

- OpenGL core contexts are always used by default when available. In
  the previous release, these were already used by default for
  Direct3D 10 and 11 applications on AMD and Intel graphics
  cards. That has been extended to all graphics cards, and all
  versions of Direct3D before 12.

- Among others, the following notable Direct3D 10 and 11 features are
  - Multi-sample textures and views, as well as multi-sample resolves.
  - Per-sample fragment shading.
  - Support for 1D textures.
  - Draws without render target views or depth/stencil views.
  - Multiple viewports and scissor rectangles per draw.
  - Depth clipping control.
  - Depth bias clamping.
  - Stream output without geometry shaders.
  - Several more capability queries.
  - Several more resource formats.

- The "depth bias clamping" feature mentioned above requires the
  ARB_polygon_offset_clamp/EXT_polygon_offset_clamp OpenGL
  extension. All Direct3D 10+ capable hardware should be able to
  support that extension, but it has come to our attention that some
  NVIDIA "Legacy Drivers" do not. We encourage affected users to
  explore whether the Free Software Nouveau drivers meet their needs.

- Several Direct3D 11 interfaces have been updated to version 11.2,
  and several DXGI interfaces have been update to version 1.6. This
  allows applications requiring those newer interfaces to start

- The first steps towards more fine-grained locking in the Direct3D
  implementation have been taken. This will be an ongoing effort to
  take better advantage of modern high core count CPUs.

- Support for using the correct swap interval is implemented, for both
  DXGI and DirectDraw applications.

- Application-configurable frame latency is implemented for Direct3D
  9Ex and DXGI applications.

- S3TC-compressed 3D textures are supported. S3TC-compressed 2D
  textures were already supported, provided the OpenGL drivers
  supported them.

- When the ARB_query_buffer_object OpenGL extension is available,
  query results can be polled with lower latency, resulting in a
  modest performance improvement in specific cases.

- Validation of Direct3D 8 and 9 resource pool and usage restrictions,
  as well as blit restrictions, has been improved.

- The Direct3D graphics card database recognizes more graphics cards.

- New HKEY_CURRENT_USER\Software\Wine\Direct3D registry keys:
  - "MultisampleTextures" (REG_DWORD)
    Enable (0x1, default) or disable (0x0) support for multi-sample
  - "Renderer" (REG_SZ)
    The backend API to target. Possible values are "gl" (default) for
    OpenGL and "gdi" for GDI.

- Deprecated HKEY_CURRENT_USER\Software\Wine\Direct3D registry key:
  - "DirectDrawRenderer"
    This has been superseded by the "Renderer" setting above.

- Removed HKEY_CURRENT_USER\Software\Wine\Direct3D registry key:
  - "StrictDrawOrdering"
    This feature was previously deprecated in favor of the
    multi-threaded command stream feature, and has been completely

*** Graphics

- A complete Vulkan driver is implemented, using the host Vulkan
  libraries under X11, or MoltenVK on macOS.

- A builtin vulkan-1 loader is provided as an alternative to the SDK

- Icons in PNG format are supported, enabling loading high-resolution
  256x256 icons.

- The standard icons include a 256x256 version to take advantage of
  the PNG support.

- Many Direct2D interfaces have been updated to version 1.2.

- New HKEY_CURRENT_USER\Software\Wine\Direct2D registry key:
  - "max_version_factory" (REG_DWORD)
    Limit the interface version of the ID2D1Factory interface to the
    specified version. 0x0 for ID2D1Factory, 0x1 for ID2D1Factory1,
    etc. By default there is no limit.

- Using an ARGB visual as default X11 visual is supported.

- The old 16-bit DIB.DRV driver is implemented using the DIB engine.

- Polygon drawing in the DIB engine is much faster for large polygons.

- A0, A1 and A2 paper sizes are supported for generic printers.

- Arrows are supported in GdiPlus.

*** Kernel

- Support for running DOS binaries under Wine is removed. When
  execution of a DOS binary is requested, an external DOSBox instance
  is launched. This doesn't apply to Win16 binaries, which are still
  supported internally.

- All the CPU control and debug registers can be accessed by kernel
  drivers, including on 64-bit.

- Events, semaphores, mutexes and timers are implemented in kernel
  mode for device drivers.

- The WaitOnAddress synchronization primitives are supported.

- Reported processor information correctly distinguishes logical and
  physical CPU cores to support hyper-threading.

- Detailed BIOS information can be queried on Linux platforms.

- The various debugger APIs support manipulating a 32-bit Wow64
  process from a 64-bit process context.

- Application settings, compatibility information and execution levels
  are recognized in application manifests.

- The various file I/O completion modes are implemented.

- Debug registers are supported on NetBSD.

*** User interface

- The infrastructure for setting DPI awareness and scaling of non
  DPI-aware applications is implemented. However, actual scaling of
  window contents is only supported on Android at this point.
  Scaling is disabled by default and can be enabled by setting the
  "DpiScalingVer" value under HKEY_CURRENT_USER\Control Panel\Desktop.

- Window class redirection is supported, enabling support of Common
  Controls version 6 features for standard USER controls like buttons.

- The standard USER controls Button, Listbox, Combobox, Edit and
  Static support version 6 features, including theming.

- The standard Task Dialog is implemented, including support for
  icons, hyperlinks, progress bars, and various other UI elements.

- Cue banners are supported in version 6 of the Edit control.

*** Desktop integration

- Exporting MIME-type file associations to the native desktop can be
  disabled with a checkbox under the Desktop Integration tab in
  winecfg.  It can be configured programmatically by setting the
  "Enable" value under

- The File Dialog can display file properties like size, times and

- The File Dialog optionally shows the Places toolbar on the left-hand

- The shell folder Public is used instead of AllUsersProfile to follow
  the behavior of recent Windows versions.

- The shell File Browser supports keyboard shortcuts to rename (F2
  key) and delete (Delete key) shell folders.

- Many standard icons are added to the Shell library.

- Shell Autocompletion is supported.

- In desktop mode the taskbar won't be displayed on top of fullscreen

- Additional names are provided for standard cursors to better match
  existing X11 cursor themes.

*** Input devices

- HID game controllers are supported in the XInput and Raw Input APIs.

- An SDL driver is implemented to make SDL game controllers
  available through the HID interface.

*** Internet and networking

- JScript has an EcmaScript compliant mode, which supports a number of
  features not available in legacy mode.

- JavaScript property accessors are supported.

- HTML style object is rewritten to support standard-compliant mode.

- HTML documents respect X-UA-Compatible HTTP header, allowing web
  pages to request specific compatibility mode. The
  HKEY_CURRENT_USER\Software\Wine\MSHTML\CompatMode key may be used to
  override the requested mode.

- MSHTML supports non-HTML elements, allowing limited SVG support.

- A number of new HTML APIs are supported.

- The proxy server can be configured through the Internet Control
  Panel applet.

- Stream I/O is implemented in WebServices.

- The Web Services on Devices API (WSDAPI) is implemented, including
  sending and receiving the various message types.

- More system information is reported through WBEM, including CPU,
  BIOS, video controller, and network adapter properties.

*** Cryptography

- Asymmetric encryption keys, as well as RSA and ECDSA signature
  verification are supported.

- The GCM and ECB encryption chaining modes are supported.

- Optimal Asymmetric Encryption Padding (OAEP) is supported in RSA

- A Kerberos security provider is implemented, supporting Kerberos

- A selection dialog for public key certificates is implemented.

- If available, GnuTLS is used on macOS in preference to the
  CommonCrypto framework.

*** Text and fonts

- Character tables are based on version 11.0.0 of the Unicode Standard.

- The new subpixel font rendering of FreeType >= 2.8.1 is supported.

- When a font face is missing, FontConfig is queried to provide
  possible substitutions.

- The font selected in the console emulator properly scales with the
  display DPI.

- Memory font resources are supported in DirectWrite.

- The builtin Wingdings font contains clock images.

*** Audio

- The Windows Media Player interfaces are implemented and support
  media playback.

- An MP3 decoder is provided as DirectX Media Object.

*** macOS

- The preloader is implemented on macOS, for better address space
  layout compatibility.

- The Command key can be mapped to Ctrl, by setting the
  "LeftCommandIsCtrl" or "RightCommandIsCtrl" values under
  HKEY_CURRENT_USER\Software\Wine\Mac Driver.

- The App Nap energy-saving feature is disabled by default in GUI
  processes. It can be re-enabled by setting the "EnableAppNap" value
  under HKEY_CURRENT_USER\Software\Wine\Mac Driver.

*** Android

- Setting the mouse cursor is supported using the APIs available in
  Android >= 7.

- The new version of the Android graphics buffer allocator API is
  supported, to enable graphics support on Android >= 8.

- Android x86-64 platforms are supported also in 64-bit mode, however
  WoW64 mode is not supported yet in the WineHQ packages.

*** ARM platforms

- Stubless COM proxies are implemented on ARM.

- The Windows calling convention for variadic functions is supported
  on ARM64.

- Exception handling and debugging is better supported on ARM64

- The MinGW toolchain is supported for cross-compilation to ARM64.

*** Built-in applications

- The Ping program provides actual pinging functionality using

- The SchTasks task scheduler program can create and delete tasks.

- The RegEdit registry editor has an improved hex editor for binary

- FOR loops are properly handled in the Command Interpreter.

- The XCopy program supports the /k (keep attributes) option.

*** Internationalization

- The Japanese 106 keyboard is properly supported.

- Translation of timezone names is supported.

- There is a partial translation to the Sinhala language.

- More locales are supported in the Resource Compiler (wrc) and
  Message Compiler (wmc).

*** Development tools

- winedbg supports debugging WoW64 processes.

- In gdb proxy mode, winedbg supports a --port option to specify the
  port used to connect to gdb.

- winegcc uses better heuristics for finding the appropriate lib
  directory for 32/64-bit cross-compiles.

- winegcc supports building native subsystem libraries.

- winegcc also looks for includes in the top-level include directory
  of the installation prefix.

- winebuild supports a -mfpu option for specifying the FPU
  architecture on ARM platforms.

- winedump supports dumping SLTG-format typelibs.

*** IDL compiler

- Application Configuration Files (ACF) are supported.

- Asynchronous interfaces are supported.

- Type and method serialization using encode/decode attributes is

- The defaultvalue() attribute is supported for pointer types.

- Generated files are always specific to the target platform. The
  target can be specified the same way as with the other tools,
  using the cpu-manufacturer-os platform specification.

- Nesting of pointers and arrays works correctly.

- Correct size and alignment are generated for encapsulated unions.

- The __int32 type is supported.

- The -robust command line option is recognized (but ignored) for
  compatibility with the Microsoft IDL compiler.

- Multiple typelibs can be generated into a single resource file.

*** .NET

- 32-bit CIL-only .NET binaries are supported on 64-bit.

- The Mono engine is updated to version 4.7.5 with some upstream Mono


- The typelib marshaller is reimplemented. It generates format strings
  and then uses the standard NDR marshalling routines; this way it
  also works on 64-bit and ARM platforms.

*** Installers

- MSI custom actions run in a separate process, enabling proper
  support for mixed 32/64-bit installers.

- Deferred installation actions are supported in MSI.

*** Build infrastructure

- The test framework supports building helper dlls inside a test, to
  allow testing features that require loading an external library.

- The test framework supports testing Windows kernel drivers.

- It is possible to build and run a WoW64 tree from inside the Wine
  source directory. Previously an out-of-tree build was required.

- A .editorconfig file is provided with the recommended indentation

*** Miscellaneous

- The Task Scheduler service and APIs are implemented.

- The Windows Management Instrumentation service is implemented.

- The OPC Services (Open Packaging Conventions, used for Microsoft
  Office XML files) library is implemented.

- The HKEY_PERFORMANCE_DATA magic registry key is partially

*** New external dependencies

- The Vulkan library is used to implement the Vulkan graphics driver.

- The Vkd3d library is used to implement Direct3D 12 on top of Vulkan.

- The SDL library is used to support game controllers.

- The GSSAPI library is used to implement Kerberos authentication.

Alexandre Julliard

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Tuesday, January 22, 2019

Working on Wine Part 6 Sending Your Work Upstream

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.

If you recall from Part 1, there are many forks of Wine. Where your fix belongs can vary depending on what fork of Wine you use, the nature of the bug you fixed, and how you fixed it.



Choosing the right place to send your fix

The ideal place for your fix is in upstream Wine. This is the origin point of all Wine forks. If you fix it in upstream Wine, then all users of Wine will eventually benefit from your work as the various forks pull in changes from upstream.

Sending your fix upstream should be the default choice for your work. If none of the exceptions below apply, or if you're unsure where your fix belongs, work with upstream first.


When upstream is the wrong choice

Your patch may be built on top of an existing patch in wine-staging. In that case, it should be sent to the wine-staging maintainers. If you, or they, think that the patch is ready to be sent upstream, then go ahead and do that instead.

If your patch fixes the issue, but you failed to fix the tests you wrote, or your patch causes some other test failures, it may belong on the bug tracker, or possibly in wine-staging.
If your patch provides a useful feature that upstream Wine is not interested in, it may belong in wine-staging.

If your patch is builds on a feature exclusive to some fork of Wine, like Proton or CrossOver, it may belong in that fork and not upstream. Work with the fork maintainers to determine if it's appropriate for upstreaming.


Upstreaming your fix

Hopefully, your patch is going upstream. Wine's patch submission process is done via email. Your patch should be sent in plain text to You should subscribe to this mailing list to avoid being placed into the moderation queue.

It is recommended to use git send-email to send the email through your mail server. You can also use git format-patch and attach the resulting file in an email client. Be careful that your mail client doesn't wrap, or otherwise corrupt, the attachment as if it were a text document.

Patches that are sent upstream should have your Sign-off. This can be applied by Git automatically with the -s switch during git commit and/or git format-patch. You must use your real name in the Author field when submitting a patch.

If you are submitting a series of patches, try to limit yourself to about four patches per submission. Your patches should be self-contained anyway, so there is no harm in submitting them in several batches. Smaller patch series are easier to review, and keep from cluttering up the mailing list if you have to re-send the series with changes.


Receiving feedback

Wine has a patch status webpage which will track the status of your patch. Your patch will be tested by the Wine Test Bot to ensure any new tests pass on various Windows versions. If the area of Wine changed by your patch has a maintainer, it will be assigned to that person for review. If not, it will be reviewed by the general community, or by the Wine maintainer.

Be patient, it may take a few days for your patches to receive review. Wine reviewers try to reply to every patch within a week, but if you don't get feedback you may send an email to wine-devel asking for a review. Be sure you are subscribed to wine-devel, as some reviews may be sent to that mailing list instead of directly back to the author.

If you received some suggestions, take those suggestions into account and send a new version of the patch. Feedback from Wine reviewers should not be seen as criticism or an attack. Wine is a very complicated piece of software, and it has a high standard of code quality for contributions. Rejections aren't made lightly—everyone wants Wine to improve. Instead, understand that there are reasons for the rejection, apply the suggestions, and resend the patch. If you do not have the time or interest in making the requested changes, consider sending your patch to wine-staging so some other person may take up the patch in the future and try to get it upstream. Or, attach it to a Bugzilla bug so it is not lost.

If your patch is accepted, then congratulations! You have just made Wine better. It's time to move on to the next bug.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.