Pages

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
  implemented:
 
  - 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
  working.

- 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
    textures.
  - "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
    removed.


*** 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
  loader.

- 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
  HKEY_CURRENT_USER\Software\Wine\FileOpenAssociations.

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

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

- 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
  windows.

- 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
  encryption.

- A Kerberos security provider is implemented, supporting Kerberos
  authentication.

- 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
  platforms.

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


*** Built-in applications

- The Ping program provides actual pinging functionality using
  IcmpSendEcho.

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

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

- 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
  supported.

- 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
  fixes.


*** RPC/COM

- 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
  parameters.


*** 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
  implemented.


*** 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
julliard@winehq.org

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 wine-devel@winehq.org. 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.

 

Friday, January 18, 2019

Wine development release 4.0-rc7 is now available for Linux FreeBSD and macOS

Wine development release 4.0-rc7 is now available for Linux FreeBSD and macOS

The Wine development release 4.0-rc7 is now available.
What's new in this release:
  • Bug fixes only, we are in code freeze.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.


Bugs fixed in 4.0-rc7 (total 13):

  20728  Multiple video players crash when opening audio or video file (MPC-HC v1.6.5, PotPlayer 1.5.x)(FilterGraph_create releases/destroys controlling IUnknown)
  26369  A.R.E.S. Extinction Agenda 1.x (.NET 2.0, XNA 3.1 game) crashes during intro ('quartz' FilterGraph2_Connect must translate HRESULT of failures more correctly)
  29461  BurnPlot (VB6 app) fails to start, complaining with "Run-time error '438'" (WshShell3 'SpecialFolders' collection 'item' method invocation fails)
  34884  Touhou Danmakufu 0.12m's font becomes distorted
  35573  gdi32:fonts test_stock_fonts() fails on Windows 7 in the Japanese and Hebrew locales
  36082  Cannot Read Text In "Question" Boxes On Microsoft Money 2005 Installation
  36084  Microsoft Money 2005 Window Going "Black" After Certain Menu Operations
  43211  NVIDIA GeForce Experience 3.x installer fails due to 'setupapi.SetupDiDeleteDeviceInfo' stub
  44796  Age of Empires II: The Conquerors is broken when CSMT is enabled
  45874  Secret Files 1-2: hardware mouse cursor corrupted
  46212  Multiple games have performance issues (Project CARS, NFS: Hot Pursuit (2010), Gas Guzzlers: Combat Carnage)
  46459  Secret Files 1-2, Ufo: Extraterrestrials: mouse cursor invisible when anti-aliasing and hardware mouse enabled
  46480  Invalid write of size 2 in ntoskrnl.exe/tests/ntoskrnl.c

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

Thursday, January 17, 2019

Working on Wine Part 5 Fixing Wine

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.

Once you've got some idea of what is causing the problem with your application, it's time to go understand how those APIs are implemented in Wine so you can fix it. You may also need to change Wine's code to debug the application in the first place.

 

Search for existing bugs


Before digging into the source, it's always useful to first search for existing bugs. You can search Wine's Bugzilla for your application, or for the symptoms you're seeing. As you begin to debug your issue, you may find other search terms to try. If you find a bug, you may find some useful analysis or work has already been done for the issue.

You may also want to look through the Wine Staging patches, especially once you have some idea of what the problem is. You may find someone has already written a patch to fix this problem, but it isn't ready to go upstream yet. You can pick up the torch and try to upstream the work.

 

Wine source layout


Wine implements the Windows operating system, which is composed of libraries, programs, and kernel functionality. You can find the code for Wine's implementation of each of those components in dlls, programs, and server, respectively. To give you some idea of how different components of Wine work together, some important, core components are listed here.
  • dlls/ntdll – This is where many of the core OS APIs are implemented, like file handling, thread creation and synchronization, timing, and much more. Applications typically use kernel32 instead of ntdll directly.
  • dlls/kernel32 – This is the application-facing interface for the core ntdll APIs mentioned above.
  • dlls/user32 – This is where much of the Windows GUI handling lives, like window creation, message handling, terminal services, and so on.
  • dlls/winex11.drv and dlls/winemac.drv – These libraries map the Windows GUI interfaces, and some other platform-specific functions, to the native platform. user32 calls into these platform drivers.
  • dlls/d3d* and dlls/wined3d – These libraries implement the Direct3D graphics API on top of the platform's OpenGL implementation.
  • programs/services – This program manages background services, both those created by Wine and those provided by installed applications.
  • programs/wineboot – This program kicks off initial prefix creation and other tasks when a prefix is booted.
  • programs/winecfg – This is Wine's configuration program.
  • server – The Wine server implements all cross-process functionality, including message routing, multi-process synchronization primitives, registry handling, and much more. The Wine server is always running if an application is running.
While debug channels are often named after the component in which they are declared (e.g. the dsound channel is declared in dlls/dsound), this is not always the case. You can use git grep to find the relevant debug trace line if it isn't obvious.

 

Writing tests


In most cases, your work should be driven by tests. Study the documentation for the relevant APIs and write tests first to confirm that Windows's implementation behaves how you expect it to. Then, change Wine's source to pass the tests that you wrote.

Wine has an extensive suite of unit tests. The unit tests comprise well over one million lines of code as of this writing. Any patch you submit must pass all of these tests. Patches should contain more tests proving that the new behavior is correct.

In general, you should focus your work on what a real application actually does. That is, you don't need to implement a bunch of unrelated functionality if the application doesn't actually need it. You should write tests to show how an application is using an API, and how Wine fails to meet its expectations. Then fix Wine to also pass those tests without breaking any existing tests. Any change to Wine has the potential to break other applications. Simply passing tests that you wrote is insufficient reason to change Wine.

You can find the tests for a given component in the tests subdirectory. For example, the tests for dsound live in dlls/dsound/tests. You will find .c files in that directory. The tests start in the START_TEST function and exercise the component being tested. The ok function demonstrates correct behavior. Again, "correct" is defined to mean "like Windows." For example:

    hr = IDirectSound_CreateSoundBuffer(ds, &bufdesc, &primary, NULL);
    ok(hr == S_OK, "CreateSoundBuffer failed: %08x\n", hr);
 
Here you can see the return value from IDirectSound::CreateSoundBuffer is expected to be S_OK. If it is not S_OK, then the test will fail.

Your tests should demonstrate how your application behaves when interacting with that API. Since you are fixing a bug in Wine's implementation of the API, your tests should demonstrate that Wine will fail without your fix. It isn't necessary, or even recommended, to fully exercise all inputs to an API in the Wine tests. Instead, be thoughtful about how your application might use the API given different inputs from the user, and write tests that reflect those possibilities.

Your tests should be self-contained. They should initialize the necessary functions, test the APIs, and then clean up before continuing. If you need to create files on disk, create them in a temporary location and/or clean them up afterwards. If your test may leave changes to the system, expect to have to clean up after a previous run that crashed, before you run your tests.

After you have written some tests, you need to verify that they pass when run on Windows. To do this locally, run make crosstest, which will use your system's mingw-w64 compiler to build a Windows executable. Run this executable on Windows in the command prompt to verify Windows's behavior. If you do not have a Windows system or VM available, you can upload your patch or test binary to the Wine Test Bot.

Once your tests pass on Windows, run them in Wine with make test. If your tests meaningfully demonstrate a Wine bug, they should fail. Now it is time to fix Wine to pass those tests, as well as all existing tests.

 

Working with Wine's source


As you develop your fix, there are some rules you should know if you intend to send your work upstream.

For better or worse, Wine does not have a coding style standard and likely never will. The rule is to try to match the surrounding code as best as possible. Especially in older code, you will find a horrible mish-mash of tabs and spaces and brace styles. Do your best to make the code no worse than it was. However, extraneous changes are discouraged as they make review difficult and looking up the source history in Git more cumbersome. If you are changing a line, or even one line in a short code block, it can be re-formatted to be less ugly than it was. But don't reformat an entire function to fit some style, no matter how ugly it is.

Wine only accepts code that adheres to the C89 standard, because some compilers that Wine cares about don't support anything later. The three most common snags here are that your code must declare its variables at the top of the block, you cannot use //-style comments, and function declarations with no arguments must be declared with void arguments:

    int some_function(void);
 
Resist the urge to gut an entire function or module and re-write it. Small, discrete changes that can be easily understood are the right way to fix Wine. Wine is more than two decades old. There is a lot of hard-won knowledge in much of Wine's source, and throwing out all of that history because it's easier than working in the existing code is not likely to pass review.

Make your changes as obviously correct as possible. Unrelated changes must be placed into their own commits. You should not introduce unused code in an early patch, which begins to be used in a later patch.

Write your patches with the reviewer in mind. It may be unintuitive, but understand that it is more important for your patch to be easy to review than make Wine's code perfect. Reviewer time is one of Wine's most valuable assets. Patches that are easier to review are more likely to pass that review.
Be aware that some tests are "flaky." This is an unfortunate reality of a system as complex as Wine. Ideally all tests would pass on all Windows and Wine environments, but due to bugs, differing platform behavior (especially window managers) and timing differences, they don't. Most modules have well-written tests that should always pass. Some, like the user32 messaging tests, and some audio and graphics tests, fail with some frequency, even on Windows.

Full Article

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

Tuesday, January 15, 2019

Working on Wine Part 4 Debugging Wine

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've made it this far, then you should have a functioning Wine build and an application installed that has some problem that you want to fix.

Debugging Wine is unlike debugging an application or even most open source libraries and software. As a Wine developer, you typically don't have access to the source of the application. So you have to be able to guess at what the application is trying to do, and then figure out why Wine is failing to meet its requirements.

Applications are often debugged with debuggers, but this is of limited use with Wine. A lot of time is spent in application code, which isn't useful to us, or in OS library or kernel code, which is also often not useful to us. Wine is just the go-between from application code to library or OS code, so debuggers tend to spend a lot more time out of Wine code than in it. Problems in Wine are also often less about bugs than they are missing features. Debuggers don't help here.

 

WINEDEBUG


Instead, most Wine debugging is done with printf-debugging. Wine developers have introduced copious logging into the libraries. When you run an application with these debug traces enabled, it will spit out large quantities of information about how the application is using the library.

You enable these logs with the WINEDEBUG environment variable. This variable takes a comma-separated list of debug channels. While it has a more complicated syntax than this, usually you just enable channels entirely. For example, to debug a networking issue, you might start with:

    $ WINEDEBUG=+seh,+winhttp,+winsock,+wininet ~/src/wine.win64/wine Steam.exe
 
This will emit a ton of output on stderr. Usually you redirect to a file:

    $ rm -f out.txt && WINEDEBUG=+seh,+winhttp,+winsock,+wininet 
~/src/wine.win64/wine Steam.exe &>> out.txt
 
Notice that the redirect is in append mode, to allow for more readable multi-threaded logging. This requires that we delete any old log file first.

This is the basic Wine debugging loop. Run the application with logging enabled, demonstrate the failure, examine the log, add more logging if necessary, and repeat until you understand the problem.

 

Debugging channels


Wine trace logs have four "severities," called TRACE, WARN, FIXME, and ERR. TRACE is just general debugging, and is silenced by default. WARN indicates some suspicious, but non-fatal condition and is also silenced by default. FIXME indicates some missing feature of Wine and will be printed by default. ERR indicates a serious problem and will also be printed by default.

Wine lets developers output logs on specific channels. These are declared in the C source files with WINE_DECLARE_DEBUG_CHANNEL and WINE_DEFAULT_DEBUG_CHANNEL. Grepping the C files for DEBUG_CHANNEL works great.

It's not always easy to determine which log channels are useful to trace. If you know what general area your problem is in, you can add channels from the relevant Wine libraries. If you don't have any idea, then a log with just +seh is a decent starting place to dig for fixmes and errs.
There are some special debugging channels.

tid and pid will prepend each log line with the Thread ID and Process ID that outputted the log line. tid is enabled by default in recent Wine.

relay will output every API entry point that the application, or other parts of Wine, make a call to. This is extremely verbose, but can be very valuable, especially if you don't know where the problem lies.

timestamp will prepend every log line with a millisecond-resolution timer. This is great if you can estimate when in the log the problem occurred, or are working with timing-sensitive code like audio.

 

Working with log files


Most WINEDEBUG logs will grow to hundreds of kB and MB of plaintext. Logs of multiple GB are not uncommon, especially relay logs. Many GUI text editors will not handle files of these sizes very well. An editor like vim is recommended.

You should also get familiar with tools like grep, head, and tail to pare log files down to manageable chunks. In particular, grep -v can get rid of uselessly repetitive log lines.
When encountering a new log, a good first step is to grep for err:, warn:, and fixme:. These can indicate problems. You'll likely get a lot of fixmes and probably some warns. If you're getting messages from areas unrelated to the problem you're examining, you can usually ignore them. For example, fixmes from the d3d channel are probably unrelated to a problem with audio.

 

Log file techniques


One generally useful technique is to find the problem and then search backwards. For example, bad pointer dereferences are a common failure. These can be found in a +seh log by searching for c0000005. Once you've found the failure in the log, you can start going backwards and if you're lucky, find some fixme or err indicating a missing feature. Or in a relay log, you might find some API that is returning a failure, like a bad HRESULT instead of S_OK.

If you don't have an obvious crash point, you can also try to find where in the log things start to go bad. For example, most applications follow a pattern of loading libraries, initializing stuff, normal application processing, then uninitializing stuff and unloading libraries. If you have an application that is quitting unexpectedly, you can search for when shutdown-related code is happening and then start going backwards to try to find the culprit.

If you have an application that fails on some specific input condition (say, clicking on some UI element), you can actually write to the log at the same time that Wine is. While Wine is debugging, run:

    $ echo '@@@@@@@@' >> out.txt
Then perform your action and observe the failure. Then run it again:
    $ echo '########' >> out.txt
Now you know the failure occurred between the at-symbols and the hashes.

Full Article

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

Phoenicis PlayOnLinux 5.0 - Alpha 2 has been released

Hi everyone!

We wish a happy and successful year! For this first day of 2019, we are glad to release the second alpha version of Phoenicis PlayOnLinux 5.


A new wine builder

We have rewritten from scratch our winebuild platform. To make it short, it is more reliable, more transparent, easier to setup and cross-platform compatible. Any project that needs to use wine could now potentially use it and take advantage of the 1828 different builds. (We admit that some of them are outdated, though).

The winebuild project is open source, uses containers. You can install it on your machine in no time if you want to build wine by yourself.

Support of new wine distributions

Speaking about wine builds, we now support 4 wine distributions:
  • Upstream wine builds are vanilla and unmodified wine (1)
  • Staging wine builds are the wine builds patched by wine-staging
  • Dos support wine builds contains wine and dosbox. (See the next feature)
  • CX contains a wine version patched by codeweavers
We plan to support proton in the next weeks.
All these wine build can be compiled directly through https://github.com/PhoenicisOrg/phoenicis-winebuild/.



(1) Except the very old versions that have a specific suffix is their names, like 1.5.3-heap_allocation_v2-avoid_deadlock, but we are going to move them anyway.

DOS Support

Winebuild now provides dos_support distribution. The way these wine binaries works is very simple: Wine launch script has been modified to detect if the given .exe is Win32 or a DOS executable. If it is a DOS executable, it will set-up a dosbox configuration that will behave consistenly with wine:
  • mount drive_c as C: on dosbox
  • if a autoexec.bat file exists inside the prefix, it will run it
  • support of custom DOS configuration per prefix
  • ...
The script framework has also been modified so that you can tweak some dosbox settings directly from a script. Here is an exemple of "advanced" script
1
2
3
4
5
6
7
8
9
wine.run(wine.prefixDirectory() + "/drive_c/The Elder Scroll 1: Arena/Arena106.exe"); // Arena106.exe is a w32 fine, wine will run
wine.dosbox()
    .memSize(64)
    .renderAspect(true)
    .cpuCycles("max 95% limit 33000")
    .renderFrameSkip(1);
wine.run(wine.prefixDirectory() + "/drive_c/The Elder Scroll 1: Arena/ARENA.BAT"); // ARENA.BAT is obviously a MS-DOS file, dosbox will run

GoG support

We've added a way to add a web browser view directly inside script wizards. Thanks to this feature, scripts can now authenticate to any website.
Phoenicis can automatically download and install GoG games from your account, as POLv4 used to do during the past years.



A complete demonstration video of gog.com support: https://www.youtube.com/watch?v=Fopp-x9Fz3g&feature=youtu.be
Also, we have made a script pattern for all GoG games: it has drastically simplified them from POLv4. The script are so much easier that we believe that they will be a lot more maintained.

POLv5 script POLv4 script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
include(["engines", "wine", "quick_script", "gog_script"]);
var installerImplementation = {
    run: function () {
        new GogScript()
            .name("Teenagent")
            .editor("")
            .applicationHomepage("")
            .author("Quentin PÂRIS")
            .gogSetupFileName("teenagent/en1installer0")
            .category("Games")
            .wineVersion(LATEST_DOS_SUPPORT_VERSION)
            .wineDistribution("dos_support")
            .executable("TEENAGNT.EXE")
            .go();
    }
};

We are planning to add tons of GoG games in the library so stay tuned!

Installation of verbs directly inside a container

You can now install verbs directly from a wine container.

Standalone packages

  • We are now providing standalone packages that can work on any distribution without the need to install JDK runtime. These packages also remove all the feature that we don't need from the JDK. In the future, there will be probably two sorts of packages, but we want to make things easier for you for now.
  • We now provide macOS packages
  • We also support flatpak


I'd like to thank once again all the developers that helped us during the past weeks, plata, madoar, and also all those of you that contributed by reporting bugs, suggesting improvements, or tested phoenicis-winebuild.

Our next goals is to focus on prefix management (change of wine version inside a prefix, add debugging tools, etc...) and performance optimization.

If you have any suggestion or encounter any bug, we encourage you to come in our Github page: https://github.com/PhoenicisOrg/. This version is still at alpha-stage, so please be indulgent.
I also take the opportunity of this news to also announce you that PlayOnLinux and PlayOnMac 4.3.4 has been released. They have been updated to support the new winebuild system, and the different windows of the application have been made resizable. It should fix the HDPI issues some of you were encoutering. We continue to maintain these versions until you are 100% satisfied with POLv5

Full Article



Putty for Mac
Putty for Mac
$15.00

https://winereviews.onfastspring.com/putty-for-mac



Saturday, January 12, 2019

Wine development release 4.0-rc6 is now available for Linux FreeBSD and macOS

Wine development release 4.0-rc6 is now available for Linux FreeBSD and macOS

What's new in this release:
  • Bug fixes only, we are in code freeze.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.


Bugs fixed in 4.0-rc6 (total 18):

  29181  Combo box doesn't get a background in dialog editor
  40433  Fifa 11 EU demo fails to install when run from custom DVD
  40828  Switching resolution in desktop mode makes task bar redraw on top of full screen game
  43665  The Quantum Break crashes at certain place.
  45486  Byond 512.x dreamseeker will crash on loading into a ss13 station that uses shaders if run on wine 3.9 or later, but will run fine if you use 3.8
  46007  Binary Domain crashes with builtin d3dx9_43 or d3dcompiler_43
  46059  Final Fantasy XI Online: Mouse Movement Heavily Affects FPS
  46067  Crysis has lighting issues
  46200  issues printing with LTSPICE XVII X64
  46275  Some autocomplete tests fail on Win2k3 VM
  46346  ntoskrnl/tests/ntoskrnl.c shows uninitalized memory use
  46357  Cossacks 2 Battle for Europe show crashed graphics
  46359  Vietcong: shooting from weapon causes game crash
  46369  将棋所(Shogidokoro) doesn't start.
  46398  When starting Reflex Arena in Steam: "failed to init XAudio2, is DirectX 9.0c installed?"
  46403  Vietcong: crash caused by loading map/other events
  46430  Doom3 (CD version) fails to install
  46435  F1 2011 crashes with a messed up rendering in DX9 mode

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

How to SSH into a VirtualBox VM Using PuTTY for Mac

This article discusses setting up a virtual machine (VM) as a virtual private server (VPS) and accessing it using secure shell (SSH). This VM VPS can then be used to test configuration and software changes before deployment to a live VPS. A deployed VPS can usually be accessed using SSH, therefore using SSH into VPS running on a VM is good practice for a live situation. This test configuration should accurately reflect the live VPS, reducing mistakes when moving from test to production. This tutorial and guide shows how to set up a VirtualBox VM and access it via the SSH client PuTTY, replicating production world VPS access.



You should never test on live systems. Replicate the live system in a test environment. Use the test environment to try out new configurations and software. When happy with the changes deploy to the live system with confidence. Of course there is no guarantee that the changes to the live system will not cause problems. However, the chance of errors occurring is reduced. The test environment should be the same as the live systems so that changes have the same affect when deployed.

Using a VM is a good way to test a system without impacting a local machine. VirtualBox is a free application that can run VMs. This article uses VirtualBox to configure a VM as a test VPS.
A VPS running in the cloud can be replicated on a local machine using a VM. The first step is to create a local VM. Then on the local VM install the same OS as the one running on the live VPS.

Use Port Forwarding for the Test VPS Networking

By default port 22 is used for SSH, see a list of TCP and UDP port numbers in Wikipedia. VirtualBox can be configured to listen to a port on the host machine and forward any traffic for that port to a port on the VM. This is configured in the VM’s network settings.

To change the network settings the VM VPS must be powered off or suspended.  Or save the machine state with the VirtualBox VM window’s File then Close menu option.

With the VM highlighted in the VirtualBox Manager click the Settings icon or use the Machine menu and select Settings.

Under Network the Adapter 1 tab is selected, the default virtual network adapter enabled for the VM VPS. Click Advanced then click the Port Forwarding button On the Port Forwarding Rules dialog click the Adds new port forwarding rule icon. Give the new rule a name, e.g. ssh rule, the protocol will be TCP, Host IP address is blank. Choose a Host Port such as 2222, Guest IP is blank and Guest Port will be 22. Click OK to create the new rule.

Leaving the IP addresses blank means that if the host or guest IPs change then rule will still work. The host port should not be in use by another application or service (see the the Wikipedia list for common uses of ports). While 2222 is used by some products it is easy to remember as it is simply the default port 22 written twice. Use any valid port number in the range 1025 to 65535.

Install the PuTTY Terminal Emulator

The application PuTTY is a terminal emulation program, it implements Telnet, SSH and other network protocols. PuTTY can be used for remote connections to Windows or Unix type machines, such as a Linux based VPS.

Using PuTTY to SSH into VPS Running on a VM

Open PuTTY, start a new session, the Hostname is localhost (your machine), which is the same as entering 127.0.0.1. The port is 2222, or whichever port number was set up in the port forwarding rule. Click the Open button.

The first time PuTTY connects to the VPS a security alert is shown. Confirm that the VPS is the valid by selecting Yes (it is running on the VM on the localhost). By selecting Yes the alert will not appear next time. A terminal window will appear and if everything is configured correctly the login prompt will be available. Log in as root with the password set during install. Run a command such as ls to list the files in the directory.

Typing logout will end the session and close the PuTTY window.

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.

Purchase Putty 9.1.0 now and have Telnet SSH FTP SCP on your Mac made easy!

Friday, January 11, 2019

Working on Wine Part 3 Using Wine as a Developer

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.

Now that you have Wine built, try running it:

    $ ./wine.win64/wine winecfg
 
This should pop up a winecfg dialog. If not, something has gone wrong.
The wine executable in the 64-bit build directory is your primary interface for running Wine. Use it to install whatever software you are trying to get functional:

    $ cd ~/software/MyFavoriteApp/
    $ ~/src/wine.win64/wine Setup.exe

 

Wine prefixes


On first run, Wine sets up a virtual Windows filesystems containing a C: drive and a bunch of other files to mimic a real Windows installation. The virtual Windows filesystem is called a "prefix." The default Wine prefix is located at $HOME/.wine/. You can override this location with the WINEPREFIX environment variable. This can be useful to set up experimental prefixes which you can destroy later without affecting other prefixes.

A typical Wine prefix looks like this:

    ./dosdevices/
                 c: -> ../drive_c
                 com1 -> /dev/ttyS0
                 com2 -> /dev/ttyS1
                 com3 -> /dev/ttyS2
                 com4 -> /dev/ttyS3
                 d:: -> /dev/sr0
                 z: -> /
    ./drive_c/
              Program Files/
              users/
              windows/
    ./system.reg
    ./userdef.reg
    ./user.reg

The dosdevices folder contains DOS drives in the form of symlinks to folders or special devices. When an application tries to open C:\some_file.txt, the c: symlink here will cause Wine to instead open $WINEPREFIX/dosdevices/../drive_c/some_file.txt.

The drive_c folder is where the contents of a typical Windows installation live, like the Windows folder and the Program Files folders.

The .reg files contain Wine's representation of the Windows registry. These are stored in a format similar to the Windows regedit .reg format. Rather than use regedit, you can actually edit these files with a text editor directly to modify the registry (though you shouldn't do that while Wine is running).
The application you installed is probably located in Program Files. You can change into that directory and go poke around its files, just like you could on Windows. You can also run Wine from that directory:

    $ cd '~/.wine/drive_c/Program Files (x86)/Steam/'
    $ ~/src/wine.win64/wine Steam.exe

If you are running applications directly like this, be mindful of your working directory. While many applications aren't sensitive to this, some assume that you launched it from the directory specified in the shortcut file that it created. This is not always the same directory in which the executable lives.

Running Wine from a build directory


If you run Wine from a build directory, like we have been here, then Wine will look up its library files from that build directory. This is as opposed to running from a system installation, where it will look up libraries in /usr/lib/wine, for example. This means that you can make changes to one Wine component, build just that one component, and then run Wine and observe the changes. No need for a top-level make or an install round trip.

Native vs built-in components


By now, you should understand that Wine is capable of running arbitrary software that was written for Windows. This includes software and libraries that Microsoft has written. Many of the components that Windows applications depend on are distributed with the application in the form of "redistributables," which contain Microsoft-written libraries. While these weren't intended for Wine, they are Windows applications like any other, so they do work in Wine.

Typically these redistributables drop DLLs into C:\windows\system32. When Wine is asked to load some DLL from system32, it will notice that these libraries are not Wine DLLs and will determine what to do on a per-library basis. The technical details of this are beyond the scope of this guide, but you can control whether Wine will prefer the Microsoft-owned DLLs (called "native") or the Wine-created DLLs (called "built-in") by using winecfg.

Since Wine tries to reimplement Microsoft code, these native libraries are by definition "correct." And unfortunately, Wine is not yet perfect. As a result, software running against native libraries will often work better than when running against Wine DLLs. This can be useful for end-users who just want to run their software.

However, you must be very careful when using native DLLs as a developer. Wine developers must never reverse-engineer actual Microsoft-owned code, and that includes using native libraries and using Wine's debugging features to determine what they are doing. There are no exceptions to this rule, so please understand the native vs built-in state of any libraries you are working on or debugging. Any developer found to be reverse-engineering in this manner may be banned from contributing to Wine. The correct way to determine the behavior of native components is to write software like any other application developer and test the behavior of those components as a black box. This will be discussed more later in these guides.

Fake DLLs and .dll.so files


On a Windows system, system libraries are installed into C:\windows\system32 (and C:\windows\syswow64 for 32-bit DLLs on a 64-bit system). Wine also installs DLLs into this directory. Some applications actually open these files directly and expect them to be valid Windows DLLs. However, Wine does not actually use the DLL file format for most of its own libraries. Instead these "fake DLLs" simply instruct Wine to load its real libraries, in whatever format is native to the underlying operating system (e.g. ELF).

As discussed above, Wine's libraries live in the build tree if you are running Wine from the build tree. They are named with the .dll.so extension. If Wine was installed someplace, then they will live in the lib/wine directory, for example in /usr/lib/wine and /usr/lib32/wine/. If you make changes to a Wine library and want to replace a single component in an existing Wine installation, you can just copy the .dll.so file into the appropriate location. Modifying the fake DLL in the Wine prefix will do nothing useful.

Tip: Virtual Desktop


Wine can be configured to run inside of a "virtual desktop." This is a single window, inside of which all of the Windows applications run. This can be extremely useful when testing fullscreen games, as this will prevent them changing the display resolution and you can still access other windows on your desktop. See the Graphics tab in winecfg.

Full Article

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

Tuesday, January 8, 2019

Working on Wine Part 2 Wine Build Process

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

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.

Wine is effectively an operating system, including all of the libraries that a Windows system provides, such as support for 3D graphics, networking, audio, and a graphical user interface, as well as dozens of support libraries that software can use like XML parsers, file format readers and writers, multimedia playback, and much more. As such, it is a very complex piece of software. Building Wine is not a trivial task.

Much of this process depends on your particular operating system, and operating system version. This guide will not get into particulars for every operating system, but instead describe the process in general. Specific guides are available at the WineHQ Wiki.

Acquiring Wine


While you can grab the Wine source from many places, the only useful place for Wine developers is to clone the Wine Git repository.

Wine uses the typical configure && make && make install process of other autoconf-based software projects.

Choosing 32-bit or 64-bit


Microsoft Windows started shipping support for 64-bit software in the mid-2000s. Wine also has support for running 64-bit Windows software. The way this works in Wine is you effectively build it twice: once for 64-bit software and again for 32-bit software. Wine will choose the correct library architecture for a given executable at runtime.

Unfortunately, building for both architectures can be complicated on Linux. Many Linux distros have poor support for installing software for multiple architectures. Since most of the software that distros support is open source, and since open source software can be built for any architecture, there is little reason to support alternate architectures. However, the Windows software that you want to run is likely to require 32-bit support. Distros that do provide multi-arch support often do it only for Wine. To be blunt, that's a fairly small usecase, and so these 32-bit libraries are often treated as second class citizens.

macOS is even worse. Apple is dropping 32-bit support entirely sometime in 2019. No one knows exactly what this will mean for users of unsupported, 32-bit-only software, including Wine users, but it doesn't look good.

In any case, 32-bit support is required to run most Windows software, so it is effectively required if you want to build Wine. It is also strongly recommended that you build 64-bit Wine as well, since more and more Windows software is being built for the 64-bit architecture. This guide will show you how to build both.

Building Wine


By default, configure will run in 32-bit-only mode. To support both 64- and 32-bit software (called "WoW64"), we want to first build 64-bit Wine and then make a build of 32-bit Wine which references the 64-bit Wine.

Wine's configure script will search your system for the libraries Wine needs to run Windows software. It takes a while to run. At the bottom of the output, it will warn you about any missing packages. Any missing packages that are critical will be marked with WARNING text. You are strongly suggested to install these missing packages before continuing, or your Wine may be missing critical features.

For example:

    $ cd src/
    $ mkdir wine.win64
    $ cd wine.win64
    $ ../wine/configure --enable-win64
    [ much truncated output ]
    configure: vkd3d 64-bit development files not found, Direct3D 12 
won't be supported.
    configure: WARNING: libjpeg 64-bit development files not found, JPEG 
won't be supported.


You can see my system is missing the 64-bit VKD3D package. This is OK, since I don't care about Direct3D 12 support for the applications that I want to run. On the other hand, if I did want to run some Direct3D 12 games, then I would need to fix this problem and re-run configure.
However, it is also missing the libjpeg package. This is bad news. Lots of applications will require JPEG support and may behave badly if it fails, so Wine gives me a big WARNING. I should install 64-bit libjpeg and re-run configure.

Continue installing packages and re-running configure until you are happy with the missing package state. Then build Wine with make. A typical Wine build for a single architecture can take between 20 and 60 minutes, depending on the speed of your CPU and hard drive. It is strongly recommended to run make with a -jN flag appropriate to your CPU count. ccache will also significantly speed up future Wine builds. You can build Wine with ccache using CC='ccache gcc' at configure-time.

Hopefully your build will complete without errors. At this point, you can run 64-bit Windows applications. However, most Windows software does require 32-bit support at some point, often for the installer or some background process and services. So let's get a 32-bit build started, using the same process:


    cd ../
    mkdir wine.win32
    cd wine.win32
    ../wine/configure --with-wine64=../wine.win64
    [ much truncated output ]
    configure: vkd3d 32-bit development files not found, 
Direct3D 12 won't be supported.
    configure: WARNING: libjpeg 32-bit development files not found, 
JPEG won't be supported.
    configure: WARNING: libpng 32-bit development files not found, 
PNG won't be supported.
    configure: WARNING: libxml2 32-bit development files not found 
(or too old), XML won't be supported.


Oh my, far more errors here. You need to install the 32-bit versions of all of the same packages. How to do this, and what packages are available in 32-bit, is going to vary widely between distros, and we won't cover this here. Refer to the Wine Wiki for your particular distro.
Again, when you are happy with the state of your packages, run make and go grab lunch. When it's done, you will now be able to run 64- and 32-bit Windows applications in Wine.

Building crosstests


The last stumbling block is cross-compiling the tests so that they can be run on Windows. This isn't technically required the Wine testbot will build a patch file and run it on Windows for you—but it will greatly speed up your development process if you can build the tests locally and run them in a Windows VM that you control.

To build the crosstests, you must have mingw-w64 installed at configure-time. Availability will vary by distro. Run make crosstest at the top-level of the Wine tree to build all of the crosstests.

Full Article

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

Saturday, January 5, 2019

Unofficial Wineskin Winery-1.8.2

The following Version of Winery I consider stable so I'm adding it as a release.

Functions on OSX10.8 > macOS10.14 including the EngineRepacking feature.
This was verified by downloaded and Engine and creating a Wrapper on OSX10.8.

Link to source code

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

Friday, January 4, 2019

Wine development release 4.0-rc5 is now available for Linux FreeBSD and macOS

Wine development release 4.0-rc5 is now available for Linux FreeBSD and macOS

What's new in this release:
  • Bug fixes only, we are in code freeze.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.


Bugs fixed in 4.0-rc5 (total 14):

  32218  LTSpice: Objects not resized when the window is resized
  32221  LTspice: component drawing issues when moving
  33719  comctl32:propsheet custom window proc test failure
  34334  MetaTester 5 never sends or receives data
  38721  Resident Evil 5 Gold Edition (Steam) fails to run
  39959  Growtopia v2.20->v2.14 fails (was v2.11 fails) to  run with unhandled exception on x86-64 (2.09 & 2.13 did run ok)
  44485  Delphi 7 debugger generates new exceptions by itself
  45719  comctl32:treeview test_right_click depends on mouse pointer position
  45917  battle.net launcher and mouse position on high DPI monitor
  45984  Skyrim Special Edition does not get past loading screen on high core count or high memory systems
  46266  tzres is constantly being loaded/unloaded when TimeZone information is queried.
  46328  Installer for Tanglet 1.5.3 crashes at target directory selection
  46352  TreePad X Enterprise 12GB (single user) v7.17.0: Generates Error on Startup
  46353  TreePad X Enterprise 12GB (single user) v7.17.0: Horizontal Ruler/Scale Is Different on Startup and Margins Are Different on Open Database

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

Thursday, January 3, 2019

Working on Wine Part 1 The Wine Ecosystem

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.

 

What is Wine?


Wine is an open source reimplementation of Microsoft's Windows operating system on top of various Unix operating systems. It primarily targets Linux and macOS, but can also be run on other systems like FreeBSD, NetBSD, and Solaris. What this means for users is that they can run software that was made for Windows on other operating systems.

Wine does not contain any Microsoft-owned code, so there is no need for a Windows license to run Wine. Instead, the Wine developers have rewritten components of the Windows operating system such that software run in Wine will think it is running on Windows, even though it is actually running on Linux, for example.

As a simple example, consider the Windows CreateFile API. On Windows, an application could call:

    CreateFileA(
        "C:\\some_file.txt",   //lpFileName
        GENERIC_WRITE,         //dwDesiredAccess
        0,                     //dwShareMode
        NULL,                  //lpSecurityAttributes
        CREATE_ALWAYS,         //dwCreationDisposition
        FILE_ATTRIBUTE_NORMAL, //dwFlagsAndAttributes
        NULL                   //hTemplateFile
    );
 
Wine will take that CreateFileA call and turn it into a Unix open call:
    open(
        "/home/aeikum/.wine/drive_c/some_file.txt", //path
        O_WRONLY | O_CREAT,                         //oflag
        0644                                        //creation mode
    );
 
The file handle will be returned back to the application, which can then write to the file with a similar implementation mapping WriteFile to Unix's write. Of course the actual implementation of CreateFileA in Wine is far, far more complicated than this (consider the path conversion, for example), but this gives you the gist of what Wine does.

Wine Forks


Since Wine is an open source project, anyone is free to make copies of it and modify it to suit their needs or the needs of their users. There are hundreds of Wine forks, but a few of them have gained prominence and are described here.

"Upstream" Wine


Website: https://www.winehq.org/
This is the "official" version of Wine, from which all other forks are derived. When someone refers to "Upstream" Wine, they are talking about this project. Wine is primarily focused on correctness. Wine contains extensive unit tests which demonstrate the behavior of Windows, and requires that most patches provide tests. All patches must pass the existing tests to be accepted. There is also a strong focus on code quality. Wine is a very large project (it is literally an entire operating system, including a GUI), so technical debt is strongly avoided to keep the project maintainable going forward.

Wine Staging


Website: https://wiki.winehq.org/Wine-Staging
However, Wine's strict patch acceptance requirements means that lots of patches that are unproven, wrong, or dangerous, but useful for users today, would languish in private forks or on the bug tracker. The Wine Staging project (also spelled "wine-staging") is an attempt to gather and maintain these useful patches so users can easily take advantage of them. The Wine Staging community also works to upstream these patches into Wine, so their benefits become available for all Wine users and forks, while also lowering Wine Staging's own maintenance burden. It can also serve as a "testing grounds" for patches which are difficult to prove with unit tests before they are accepted upstream.

CrossOver


Website: http://www.codeweavers.com/
CrossOver is a commercial fork of Wine sold by the CodeWeavers company. It contains many patches that are application-specific hacks and not appropriate for upstreaming. CodeWeavers also maintains an application compatibility database which will pre-install some software components and otherwise modify the Wine environment so that certain applications work better. However, CodeWeavers strongly prefers to implement features correctly and send that work to upstream Wine. CodeWeavers employees perform a significant portion of the work done on Wine.

Proton


Website: https://github.com/ValveSoftware/Proton/
Proton is a fork of Wine created by the Valve software company, which is integrated with their Steam software, a major video game and software distribution platform. Proton is focused on providing a seamless experience for Steam users to run Windows titles on Linux. Like with CrossOver, most of the contributions to Proton are also sent to upstream Wine.

Other forks


There are many, many other forks of Wine. Some are packaged with commercial software and sold as macOS and Linux software. Others are one-off forks created by users for a specific application.

Developing for Wine


Wine isn't perfect, and it's likely you will run into an inadequacy or a bug in your day-to-day Wine usage. Perhaps you are interested in fixing Wine so it will run your application or game, or maybe your employer would like to use Wine and pay you to fix it. This guide will introduce you to how you can build, debug, and fix Wine, and how to send those fixes upstream.

Full Article

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