f69dbaa1ae
This is a preliminary ARM64 platform support for wxWidgets at "it compiles" stage. This will allow building and testing wxWidgets based apps for oncoming Windows 10 ARM64. Requirements: - Visual Studio 2017 Update 4 or later with Visual C++ compilers and libraries for ARM64 component installed Building: 1. Open command prompt. 2. Change directory to build\msw subfolder. 3. Run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_arm64.bat" once. 4. Use `nmake TARGET_CPU=ARM64 ...` to build required flavor of wxWidget libraries. Notes: 1. Building of *.sln/*.vcxproj files does not support ARM64 yet. This requires to hardcode Windows SDK to 10.0.15063.0 or later in *.vcxproj files, which would render them non-compilable in older Visual Studio versions. Microsoft is aware of this issue and is planning a fix in the next version of Visual Studio. 2. wxmsw31ud_gl.dll does not build yet. Awaiting Microsoft to deliver missing opengl32.lib for ARM64. Please, specify USE_OPENGL=0. Closes https://github.com/wxWidgets/wxWidgets/pull/923 |
||
|---|---|---|
| .. | ||
| dll.bkl | ||
| dll_vc7_my_dll.vcproj | ||
| dll_vc7_sdk_exe.vcproj | ||
| dll_vc7_wx_exe.vcproj | ||
| dll_vc8_my_dll.vcproj | ||
| dll_vc8_sdk_exe.vcproj | ||
| dll_vc8_wx_exe.vcproj | ||
| dll_vc9_my_dll.vcproj | ||
| dll_vc9_sdk_exe.vcproj | ||
| dll_vc9_wx_exe.vcproj | ||
| makefile.bcc | ||
| makefile.gcc | ||
| Makefile.in | ||
| makefile.unx | ||
| makefile.vc | ||
| my_dll.cpp | ||
| my_dll.h | ||
| README.txt | ||
| sdk_exe.cpp | ||
| wx_exe.cpp | ||
This Windows-specific sample demonstrates how to use wxWidgets-based UI from
within a foreign host application that may be written in any toolkit
(including wxWidgets).
For this to work, you have to overcome two obstacles:
(1) wx's event loop in the DLL must not conflict with the host app's loop
(2) if the host app is written in wx, its copy of wx must not conflict
with the DLL's one
Number (1) is dealt with by running DLL's event loop in a thread of its own.
DLL's wx library will consider this thread to be the "main thread".
The simplest way to solve number (2) is to share the wxWidgets library between
the DLL and the host, in the form of wxWidgets DLLs build. But this requires
both the host and the DLL to be compiled against exactly same wx version,
which is often impractical.
So we do something else here: the DLL is compiled against *static* build of
wx. This way none of its symbols or variables will leak into the host app.
Win32 runtime conflicts are eliminated by using DLL's HINSTANCE instead of
host app's one and by using unique window class names (automatically done
since wx-2.9).