Freerdp client mac os

Системный интегратор

Установка Windows 8.1 Preview

Напоминаем, что ISO образ дистрибутива Windows 8.1 Вы можете скачать с официального сайта Microsoft, разработчика Windows 8.1. Запишите ISO образ установочного диска на DVD диск или USB flash диск, в виртуальную машину VirtualBox операционную систему Windows 8.1 можно устанавливать непосредственно с ISO образа дистрибутива.

Начало установки Windows 8.1 на компьютер.

Выбор языка для Windows 8.1

Запуск инсталляции Windows 8.1

Лицензионное соглашение Windows 8.1

Выбор типа установки Windows 8.1. Первый вариант подходит для установки поверх старого Windows с сохранением личных папок и файлов. Второй вариант — установка на новый компьютер, или новая установка Windows с очисткой всего жесткого диска.

Выбор жесткого диска для установки Windows 8.1

Следующий этап довольно длительный. Установка Windows 8.1 на жесткий диск.

Предварительная настройка внешнего вида Windows 8.1

Выбор стандартных параметров для Windows 8.1

Создание Вашей учетной записи на портале microsoft.com для поддержки Windows 8.1 и синхронизации Вашей информации на нескольких Ваших устройствах с Windows 8.

Следующие два экрана — нужны для защиты сайта microsoft.com от хакеров.

Настройка облачного хранилища.

Поздравляем, Windows 8.1 установлена на компьютер и готова к работе.

Источник

👩🏼‍💻 macOS — RDP to a Windows Machine 💻

How to connect from Mac to a Windows machine

How do you connect from macOS to a Windows machine?

Remote Desktop Protocol ( RDP) is a proprietary protocol developed by Microsoft, which provides a user with a graphical interface to connect to another computer over a network connection. The user employs RDP client software for this purpose, while the other computer must run RDP server software.

So how can I RDP from macOS? Let’s see… 🤔

#3 — Parallels Client

• It is Free
• Easy to manage predefined connections

• Very unstable and keep disconnecting when I use it

#2 — Microsoft Remote Desktop 10

• Developed by Microsoft
• It is Free

• It doesn’t seem to do auto-login even when storing the credentials

#1 — FreeRDP

• It is Free
• Opensource
• Faster and lighter than the rest
• Can do autologin
• Fully configurable

• Command-line arguments
• You need to know how to use it

FreeRDP is by far my favorite! Let’s see how to use it… 🧐

Installing

Using

Once installed, simply execute from your terminal shell:

Now, let’s go over the command-line arguments I am using:

So I am able to:

• Auto-login. No need to enter my credentials each time I log in
• Share the clipboard and copy from Windows and paste to in macOS
• Share my home directory with Windows and copy files from and to

These are extremely useful features! Thank you FreeRDP 👏🏻

Final Thoughts

I tried only “Free” products. If any software provider wants to give me some of his/her commercial product for a test run, just gimme a shout 😊

Источник

Полнофункциональный RDP клиент — FreeRDP

Не секрет, что в современном мире без продуктов Microsoft практически не обойтись. Однако во многих случаях получается так, что гораздо эффективней использовать на рабочих компьютерах системы на базе GNU/Linux, а не Windows. Это значительно упрощает администрирование и сокращает расходы, предоставляя при этом пользователям гораздо больше легкодоступного функционала. Но что делать с теми приложениями, которые работают только под Windows и которым нет подходящего аналога в мире Linux? Поскольку обычно таких приложений единицы (иначе просто нету смысла ставить Linux на рабочий компьютер), то разумным выбором может стать использование терминальных серверов, работающих под серверными ОС от Microsoft. Кроме того, Linux лучше всего подходит для любых тонких клиентов, поскольку адекватных версий Windows для них просто не существует.

В любом случае необходимо уметь подключаться к терминальным серверам Windows. Для этого в MS был разработан свой протокол удалённого рабочего стола — RDP. Однако до недавнего времени для Linux существовал единственный открытый клиент для работы с этим протоколом — rdesktop. К сожалению, его развитие давно остановилось, и он испытывает огромные трудности при взаимодействии с современными версиями Windows.

Но недавно тихо и незаметно проект rdesktop был форкнут, в результате чего на свет появился новый открытый RDP клиент — FreeRDP. Первый же релиз этой программы разом исправил большинство известных проблем rdesktop, и проект продолжает активно развиваться. Почему-то появление столь полезного приложение обошли вниманием, поэтому я и решил опубликовать этот пост, чтобы хоть как-то исправить эту ситуацию и рассказать всем о существовании нормального RDP клиента для Linux. Под катом — описание возможностей FreeRDP и немного про отличную графическую оболочку Remmina для него.

FreeRDP

Официальный сайт проекта — www.freerdp.com

Там же можно найти описание возможностей текущей версии и планы на будущее. Основные отличия от rdesktop:

• Произведён значительный рефакторинг кода. Пользовательский интерфейс полностью переписан и отделён от основной библиотеки, реализована система плагинов.
• Код максимально приведён в соответствие со спецификацией RDP от Microsoft и подробно комментирован.
• Переписана работа с клавиатурой — больше никаких проблем с раскладками.
• Переписана работа с принтерами, звуком и другими пробрасываемыми устройствами и сервисами.
• Исправлены проблемы с указателем и лицензиями при подключении к серверу терминалов Windows 2008.
• Реализовано кеширование графики (bitmap caching), что позволяет значительно повысить производительность.

Поломанные и убранные возможность rdesktop:

• В данный момент не реализована поддержка проброса COM портов и поддержка смарт-карт.
• Убрана поддержка режима SeamlessRDP в пользу реализации RemoteApp, которой правда тоже пока что нет.

Remmina

Кроме того, один из самых удобных графических менеджеров подключений к удалённым рабочим столам Remmina с версии 0.8 перешёл на использование FreeRDP в качестве RDP клиента.

В версии 0.8 также реализована поддержка .rdp файлов Windows, все протоколы теперь являются отдельными плагинами, добавлена поддержка IPv6 и произведено много мелких улучшений и исправлений ошибок.

Источник

Freerdp client mac os

Internally, we use the Jenkins continuous integration environment to build all binaries whenever a commit to the repository at github is performed. Furthermore, we use the OpenSuSE build service to build additional packages for several linux distributions whenever our internal jenkins has successfully built a new version.

Source

You can download a tarball (or zip) of the current source at github

Windows installer

New versions are automatically published, so just fetch the latest installer from here. The installer creates a new service which starts automatically.

Linux packages

Debian and Ubuntu

As Debian does not provide a means to automatically import a repository’s GPG-Key or any repository URL, you have to do that manually:

• Import the key, using the command wget -O — http://download.opensuse.org/repositories/home:/felfert/Debian_6.0/Release.key | apt-key add —
• Add the following line either in the file /etc/apt/sources.list or in a new file inside the directory /etc/apt/sources.list.d/ :
  • For Debian 6.0 (Squeeze), use the following line:
    deb http://download.opensuse.org/repositories/home:/felfert/Debian_6.0 ./
  • For Ubuntu 10.10 (Maverick Meerkat), use the following line:
    deb http://download.opensuse.org/repositories/home:/felfert/xUbuntu_10.10 ./
  • For Ubuntu 11.10 (Oneiric Ocelot), use the following line:
    deb http://download.opensuse.org/repositories/home:/felfert/xUbuntu_11.10 ./
  • For Ubuntu 12.04 (Precise Pangolin), use the following line:
    deb http://download.opensuse.org/repositories/home:/felfert/xUbuntu_12.04 ./
• Finally, use the following command to install the wsgate daemon:
  apt-get update; apt-get install wsgate

CentOS 6

Fetch freerdp.repo, and put it into /etc/yum.repos.d/

After that, run the command yum install wsgate .

Fedora (15 — 17)

Fetch opennx.repo, and put it into /etc/yum.repos.d/

After that, run the command yum install wsgate .

Источник

Freerdp client mac os

Debian / Ubuntu / Mint

ffmpeg and gstreamer development libraries are available in the Restricted Formats community repository.

CentOS / REHL / Fedora

The version of cmake available in the CentOS repositories is too old, use a more recent version:

CMake Build System

FreeRDP uses CMake as its build system. CMake is not an ordinary build system: it generates project files for other build systems to use. This means that we have only one set of scripts to maintain while having the flexibility of using any of the build systems supported by CMake. For instance, FreeRDP developers can use Visual Studio, Xcode, Eclipse, or just plain regular makefiles without having to separately maintain project files for the development tools they are using.

FreeRDP requires CMake 2.8, but it is highly recommended to use the very latest builds available from the CMake website (www.cmake.org). This is because certain useful features are available only in certain versions that we cannot require since they are too recent. Using an older version of CMake 2.8 will work, but some features taking advantage of functionality present in more recent CMake releases may be disabled. For instance, FreeRDP offers a monolithic build option that combines all libraries into a single one using functionality found in CMake 2.8.9. If you are using CMake 2.8.8, this option will be disabled.

Recent CMake builds are available from the CMake download page:

CMake is packaged by most Linux distributions and should be easy to install. However, since FreeRDP leverages some of the newest CMake features, it is very likely that the version packaged for your system is not the latest one. In this case, simply download the CMake Linux build from the CMake website and install it manually to the appropriate location.

The easiest way to install CMake on Mac OS X is by using the latest build available on the CMake website. Alternatively, one can use common Mac OS X package manager such as homebrew to install CMake.

Installing CMake on Windows is fairly straightforward. Download either the installer of the zip version of the Windows build from the CMake website. Using the installer is simpler, but you might want to consider choosing the zip archive if you need to work from a machine where you do not have sufficient rights to run an installer.

Git Version Control

FreeRDP is hosted on GitHub, and uses git for version control. Git is one of those tools that is extremely powerful but a bit hard to grasp at first. Luckily, a lot of the complexity of git is made much simpler through the GitHub collaborative coding interface, and provides us with a functional workflow for accepting contributions with minimal overhead.

If you are new to FreeRDP and don’t want to bother learning the git basics for now, feel free to simply download a source tarball from GitHub and move on to the next step. However, you will eventually have to learn it, especially if you want to synchronize your work with the latest sources, or contribute your changes back to the community. If you are not so sure about how to contribute changes which have not been done cleanly with git, ping one of the developers in the IRC channel. It’s never fun to get contributions in the form of tarball in an email, but we’ll take it anyway. Please understand, however, that since this require much more effort on our side, clean integration of the changes will only happen when time allows for it.

Git is packaged for most Linux distributions and should be easily obtained. Otherwise, and for all other platforms, pre-built packages are available from the Git download page (http://git-scm.com/downloads)

Many other third-party Git packages exist for various operating systems. On Windows, git can be installed in Cygwin http://www.cygwin.com/, or through msysgit http://msysgit.github.com/

Configuring Git can be tricky, especially for the part where one has to generate SSH keys to be used for authentication with GitHub instead of passwords.

One does not necessarily need to use GitHub, but unless you know what you are doing you should simply create a GitHub account and follow the regular GitHub workflow.

GitHub offers extensive help which everyone should refer to: https://help.github.com/

Alternatively, the Pro Git book is available for free online: http://git-scm.com/book

The Git Reference is concise, small and to the point: http://gitref.org/

Along with the GitHub help, there is an excellent step-by-step introduction to GitHub on the GitHub Learn website: http://learn.github.com/p/setup.html

If you need more assistance getting started, please come on IRC and we’ll help you.

In debian-based distributions, the build-essential package installs GCC and common development tools necessary for C/C++ development.

Xcode is the easiest way develop for Mac OS X, and is distributed for free on the Mac App Store.

The Xcode command line tools are not installed by default with Xcode and are necessary:

• On the Xcode menu, click Xcode and then Preferences
• Select the Downloads tab from the Preferences panel
• Select the Components sub-tab from the Downloads tab
• Select Command line tools and click install on the right

Whenever Xcode is updated through the Mac App Store, it tends to remove SDKs for older versions of Mac OS X to only keep the new ones. In order to provide better backwards compatibility, one can download older releases of Xcode and manually install the missing SDKs in newer versions of Xcode. This process has to be repeated whenever Xcode is updated.

• Download the last release of Xcode containing the SDK you want and mount it.
• Right-click the Xcode package, select «Show Package Contents».
• Browse to Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs.
• Save a copy of the desired SDK like «MacOSX10.6.sdk» for later.
• Install Mac OS X SDKs to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs.

Mac OS X 10.6 Snow Leopard SDK: Xcode 4.3.3

Mac OS X 10.7 Lion SDK: Xcode 4.6.3

FreeRDP supports all versions of Windows starting from Windows XP all the way up to Windows 8. Windows development is normally done using Visual Studio 2010 or Visual Studio 2012. If you do not own a license of Visual Studio, the Express edition is available for free and should work fine.

To build FreeRDP on Windows, you will first need to install OpenSSL (see the “Prerequisites” section), along with the rest of the Windows build environment, including CMake. When installing CMake, it is recommended to select the option that adds it to the system path.

Refer to the “Build Configuration” section to learn the basic usage of CMake. For Windows, common CMake generators are “Visual Studio 2010” and “Visual Studio 2012”. There is also the “NMake Makefiles” generator which may be suitable for more advanced Windows developers who would prefer a build system that does not require the full Visual Studio IDE.

Android development can be done from Linux, Mac OS X and Windows. There are two development kits for Android: the Software Development Kit (SDK) and the Native Development Kit (NDK). The SDK is for Java, while the NDK is for C/C++. Since it is not possible to write completely native Android applications (at least not under normal circumstances), we will need both the Android SDK and NDK for FreeRDP development. The NDK alone is enough to build the FreeRDP libraries, but not enough to build a complete application.

Java Development Kit

Before installing the SDK, you will need to install the Java Development Kit. On Windows, the Sun/Oracle JDK is easy to download and install. On Linux, OpenJDK is easier to install from your distribution’s package manager.

Android SDK and NDK

Download the Android SDK and Android NDK from the Android developer website:

Extract or install the SDK and NDK to a path which is easy to locate. The Windows installer installs the SDK into “%PROGRAMFILES(x86)%/Android” by default. On Linux, using /opt/android-sdk and /opt/android-ndk is common practice. Regardless of where you choose to install the SDK and NDK, you will need to configure the ANDROID_SDK and ANDROID_NDK environment variables to point to them. It is also very convenient to add $ANDROID_SDK/tools and $ANDROID_SDK/platform-tools to your system path in order to have the Android utilities available without specifying the full path.

Once both the SDK and NDK are installed, the first thing to do (it takes some time) is to launch the “android” utility found in $ANDROID_SDK/tools. On Windows, the same utility can be launched with the “SDK Manager” found in %ANDROID_SDK%. In the SDK manager, select target Android platforms of interest, such as Android 2.3.3 (API 10) or Android 4.0 (API 14), click install, accept the licenses, and be patient because it takes time to download and install everything. The good news is that you can leave the SDK manager open while moving on to setting up the NDK.

You will need to set a certain number of environment variables to ease Android development. On Linux, this can be done by editing the .bashrc file, and on Mac OS X, this can be done by editing the .profile file.

The prebuilt toolchains that come with the Android NDK should suffice, but if you need to build your own, invoke the make-standalone-toolchain.sh script:

Where $ANDROID_STANDALONE_TOOLCHAIN is the location where you want to install your standalone toolchain.

When invoking CMake, the path to the Android CMake toolchain needs to be passed:

The Android CMake toolchain will make use of the environment variables defined in the previous section, so make sure they are correct before invoking CMake.

The Android CMake toolchain included with FreeRDP is based on the android-cmake project:

While the native portion of the FreeRDP Android port is built using CMake, the Android Java code is built using ant or Eclipse with the ADT plugin. The Android project structure is explained here:

This project is generated and maintained using the android command-line tool:

The root of the Android project tree is located in client/Android:

src: android Java code (built with ant or Eclipse)

bin: build output directory (.apk files)

jni: android native code (built with cmake)

gen: android generated code such as R.java

assets: project assets, added as-is to the .apk

res: contains XML configuration files for menus, layouts, strings, etc

libs: contains third-party libraries for both Java and native code

In order to verify that libfreerdp-android.so gets properly packaged in the .apk, simply unzip the resulting .apk files to see its contents (an .apk file is a regular zip file with a different extension).

Inside client/Android, invoke ant help to list targets:

Targets of interest are debug and release, which generate a debug or release .apk file in the bin directory:

The resulting .apk files can be deployed to actual devices or the Android emulator.

There is an Eclipse project located in client/Android, which is different from any potential Eclipse project generated by CMake in the root of the FreeRDP source tree. It can be imported in Eclipse like any other regular Eclipse project. Make sure to configure the Eclipse ADT plugin properly beforehand.

iOS development requires Xcode and the same development environment as for Mac OS X with the addition of the iOS SDK. Certain features like deploying to real devices are limited to Apple developers only.

Just like for Mac OS X SDKs, older versions of the iOS SDKs disappear when you update to a newer version of Xcode.

• Download the last release of Xcode containing the SDK you want and mount it.
• Right-click the Xcode package, select «Show Package Contents».
• Browse to Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs.
• Save a copy of the desired SDK like «iPhoneOS6.1.sdk» for later.
• Install iOS SDKs to /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs.

iOS 6.1 SDK: Xcode 4.6.3

FreeRDP includes a modified version of the ios-cmake toolchain in the cmake directory. The original toolchain can be found here:

When invoking CMake for iOS development, the iOS toolchain needs to be passed like this:

The general approach towards prerequisites is simple: avoid hard dependencies as much as possible, make soft dependencies modular and optional. This may appear a bit extreme, but it is not when FreeRDP needs to run on a very large variety of platforms with a small footprint. Convenience always comes at a cost, and we have learned from out past mistakes that in our case the extra effort is worth it.

FreeRDP’s only strong dependency is OpenSSL. All other dependencies can be made optional with the side effect of disabling the modules that depend on it. It is within our plans to make FreeRDP less dependent on OpenSSL in the future through the WinPR project: instead of using OpenSSL directly, we will implement the equivalent portions of what we need from the Windows API. The WinPR implementation of the Windows API will make use of OpenSSL and eventually add support for other cryptographic libraries. Not only will this enable OpenSSL-free builds of FreeRDP on Windows, but it will also give us an abstraction layer over OpenSSL, allowing us to add support for alternative libraries such as NSS, PolarSSL and CyaSSL.

OpenSSL is used for TLS, MD4, MD5, HMAC-MD5, SHA1, HMAC-SHA1, RSA, DES3, Base64, BigNum arithmetic and certificate validation. RDP8 support will require DTLS which is also provided by OpenSSL.

OpenSSL is packaged by most Linux distributions, and is easy to compile from source.

OpenSSL used to ship with Mac OS X until Mac OS X 10.8 (Mountain Lion). Luckily, OpenSSL ships with Xcode. Otherwise, OpenSSL can be obtained from common Mac OS X package managers such as macports.

Command-line tools are not installed by default with Xcode and are necessary.

A binary distribution of OpenSSL is maintained by “The Shining Light Productions”:

In order to use it, download both the Win32 OpenSSL installer (the full one, not the light) and the Visual C++ 2008 Redistributables. Install the Visual C++ redistributables first, since OpenSSL requires it. Install OpenSSL in the default path suggested by the installer (C:\OpenSSL-Win32), otherwise may not find it automatically. If you install OpenSSL in a path not found by CMake, you will need to use the OPENSSL_ROOT_DIR option to tell CMake where to find it.

The Visual C++ 2008 Redistributable requirement is a problem if you want to ship FreeRDP for Windows without an installer. Unfortunately, this requires building OpenSSL manually and modifying the default build scripts to link against the static Visual Studio runtime (/MT switch as opposed to the default /MD switch used by OpenSSL). There are many pitfalls along the way if you want to make a proper build of FreeRDP and OpenSSL using the static Visual Studio runtime.

A modified version of OpenSSL for Windows is available for the sake of convenience here:

The sources were deliberately put on git to allow others to consult the history of modifications from the vanilla sources that allow for an easier Windows build.

In order to build OpenSSL, you will need to install the following prerequisites

ActivePerl (http://www.activestate.com/activeperl) NASM for Windows (http://www.nasm.us/) Microsoft Visual Studio (2010 or 2012) Raspberry Perl can be used instead of ActivePerl, and other versions of Visual Studio can be used, but the build scripts provided will need to be modified accordingly.

Once prerequisites are installed, download the modified OpenSSL sources from the openssl-win32 GitHub repository. In the root of the openssl-win32 directory, you should find two batch files: win32_env.bat and win32_build.bat. Edit both of them to ensure that the path variables they use are correct for your environment.

Once the batch files are properly edited, open a command prompt and move to the root of the openssl-win32 directory. Run win32_env.bat once in order to configure environment variables. Run win32_build.bat in order to build OpenSSL. When building is complete, you should find the resulting build in the “build” directory. This directory can be renamed to OpenSSL-Win32 and moved to C:\OpenSSL-Win32 to be automatically picked up by CMake. Beware, however, that this build has only been tested at this point with FreeRDP release builds configured with the MSVC_RUNTIME=”static” option.

If your FreeRDP builds start crashing for no obvious reason when freeing memory, this is most likely the side effect of an MSVC runtime mismatch. Don’t waste your time trying to find problems where they are not: even if you think you’ve compiled everything correctly chances are that you’re fighting with the pickiness of OpenSSL builds on Windows.

Even though OpenSSL is used in Android, the headers and libraries are not part the Android NDK. This means that in order to compile FreeRDP for Android, one must first compile OpenSSL manually.

Android uses its own build system which is not supported by OpenSSL out of the box. A modified version of OpenSSL with Android build scripts is available through the Android Open Source Project (AOSP). This is the library which is used for the Android operating system itself, but not made available to application developers through the NDK.

This may look like a good deal, but further modifications to default OpenSSL Android port are required before it can be built for usage with FreeRDP, such as adding an option for a static build.

Further modifications to the OpenSSL sources have been made by the FreeRDP developers and can be found here:

Clone the OpenSSL git repository in external/openssl in the root of the FreeRDP source tree:

Ensure you have the proper environment variables configured for Android development as covered earlier. Move to the root of the OpenSSL source tree use the following command to build:

You can optionally install OpenSSL globally by copying the headers and library files to your target android platform directory:

If OpenSSL is not installed globally, you will need to manually specify its path when invoking cmake with FREERDP_ANDROID_EXTERNAL_SSL_PATH.

If ANDROID_SDK and ANDROID_NDK are set as environment variables, they will be used by cmake, reducing the size of the command. If openssl is present in external/openssl, it will be used automatically by cmake:

There is no pre-built OpenSSL iOS package, so again we have to build our own. The “iOSPorts” collection of iOS ports simplifies the task of building OpenSSL for iOS.

Launch Terminal and move to the root of the iOSPorts source tree. From there, type the following commands:

This will download, patch, configure build and install OpenSSL for iOS. The default installation path is in /tmp/iOSPorts. The important files are the include and lib directories from the OpenSSL, which we will need to copy to a location inside the iOS SDK.

The system root for the iOS SDK can be found in the following path:

Where “iPhoneOS7.0.sdk” is subject to change depending on the SDK version.

To ease installation, configure the following environment variables:

Then enter the following commands to install OpenSSL in the iOS SDK:

This procedure only has to be executed once per iOS SDK. After this, OpenSSL should be picked up automatically by CMake.

For the X11 client, you will need:

sudo apt-get install libx11-dev libxcursor-dev libxkbfile-dev libxinerama-dev

Additionally, for the X11 server, you will need:

If the X11 SDK used to ship with XCode, it was removed from its newer versions. In order to get the X11 dependencies satisfied, one has to obtain it from the XQuartz open source project:

Even if a native Windows port is available, it is possible to compile the X11 FreeRDP client on Windows using Cygwin. Please note, however, that this particular configuration is rarely tested.

Projects like FreeRDP need to conform to a large number of requirements at the same time while remaining highly flexible, portable, fast, small, modular, reusable, testable, configurable, and the list goes on. It may not be obvious, but one of the challenges of open source development is having to please everybody at the same time. Different vendors want FreeRDP built in certain ways, with nice extension points for themselves to easily maintain their extensions separately, with just about any option that fits their needs within the upstream sources. It turns out that providing everybody with what they want is possible with enough CMake scripting. Nevertheless, the task of offering build configuration for all these needs makes build configuration management quite complex.

Prior to generating build scripts for your environment, you should ensure that you have CMake installed and available within your system path. Installing CMake is covered in the previous section of this manual.

To generate build scripts, open a terminal, move to the root of the source tree, and type:

This will tell CMake to generate build scripts using the CMake scripts found in the local directory (“.”). If the command fails, you might need to invoke CMake with additional options which we will cover in the following sections. The path to the directory where the root CMake script is contained is always the last argument of the cmake command.

CMake looks for files with the name CMakeLists.txt. These files are the equivalent of makefiles, written in the CMake scripting language. A root CMakeLists.txt script can include other such scripts from subdirectories.

CMake scripts are used to generate platform-specific build scripts with the help of CMake generator. When no generator is specified, CMake attempts finding a suitable default. If it can’t find any, generation will fail. Most of the time, you will want to specify the generator of your choice using the –G “Generator Name” option. Here is a list of common generators:

• Xcode
• Unix Makefiles
• NMake Makefiles
• Visual Studio 11
• Visual Studio 10
• Visual Studio 9 2008
• Eclipse CDT4 – Unix Makefiles
• Eclipse CDT4 – NMake Makefiles

In order to generate an Eclipse project on Linux, one would type:

For simple makefiles without an Eclipse project, “Unix Makefiles” would do it.

On Windows, the generator would likely be “Visual Studio 10” (Visual Studio 2010)

On Mac OS X, the «Xcode» generator would be appropriate.

When CMake executes, it generates CMakeCache.txt, or the CMake cache. The cache stores values from previous executions. Whenever major changes happen, such as installing new dependencies, modifying the CMake scripts, or when something does not work as expected it is advised to simply delete the CMake cache and regenerate from scratch. Clearing the CMake cache is done by deleting the CMakeCache.txt file:

The CMake cache is a simple text file which looks like a simple configuration file with one option per line. You can modify it in a text editor, but it is preferable to use a specialized editor. On Linux, there is ccmake, which is ncurses-based (simple text-based GUI inside the terminal). On Windows, there is cmake-gui. These tools are very useful in order to visualize and edit the entire set of options available for the current project.

If you have to frequently regenerate the CMake, the task of entering all the options that you want over and over again will be cumbersome. A flexible build system also means a large number of options, and the process of typing all of them every time is not only slow but also error prone. This is where storing build options in a configuration file becomes useful.

Luckily for us, CMake supports using values from an initial cache when generating a new one. The format of the initial cache is the same as the CMakeCache.txt file. The easiest way to use the initial cache is to create a text file and the desired options from a previously generated cache. Since many values in the cache are specific to the current build environment, it is not recommend to copy the entire generated cache to be used as an initial cache.

Here is an example: when developing, I like to keep a working version of FreeRDP installed in a directory separated from other less stable builds. Such a build comes in handy when I need to use FreeRDP rather than develop it, and my current development build is broken. For this build, I use the following options when invoking CMake:

In the resulting CMakeCache.txt file, the options I’ve passed will look like this:

You will notice that the format in the CMake cache is a bit different that the format used at the command-line. In reality, they turn out to be the same, except that CMake guesses the parameter type when you invoke it. Values like “on/off” are recognized as BOOL, but if you were to explicitly specify the STRING data type, CMake would consider “on/off” as a STRING rather than a BOOL.

The above options can be copied in a text file which I will call “StableBuildCache.txt” for the sake of this example. The next time, instead of retyping everything, all that is needed is passing the initial cache to CMake using the –C option:

This will have the same effect as passing all the desired parameters through the command-line, with much less effort.

One of the powerful features of CMake is the ability to make out-of-source builds. Normally, a build is made in-source, meaning that build scripts and build outputs are produced in the same directories as the sources. An out-of-source build, as the name says, produces build scripts and build outputs outside of the sources.

To generate out-of-source build scripts, invoke CMake from a directory different from the source tree, while providing the path to the directory where the root CMake script is contained. For instance, if I have my sources in

/src/FreeRDP, but I want to build everything inside the

/build/FreeRDP directory, here is what the command would look like:

Where the current working directory is

CMake options are passed to the cmake command, prefixed with –D (D for Define). BOOL options are either ON or OFF. STRING options are just regular strings, and can be put between quotes.

CMAKE_BUILD_TYPE (STRING [Release]): Defines the build type, usually Debug or Release.

BUILD_SHARED_LIBS (BOOL [OFF]): Build libraries with an unspecified build type as shared libraries. This option is turned on by default in FreeRDP.

CMAKE_INSTALL_PREFIX (STRING): Path prefix for installation. On Linux, this is /usr/local by default.

MONOLITHIC_BUILD (BOOL [OFF]): Combine smaller libraries into single, larger, monolithic libraries. In monolithic build mode, there is a single libfreerdp instead of multiple libraries such as libfreerdp-core, libfreerdp-cache, libfreerdp-utils, etc.

STATIC_CHANNELS (BOOL [ON]): Build all channels statically, including channels normally built as plugins. Client static channels are bundled in libfreerdp-client, and server static channels are bundled in libfreerdp-server.

BUILD_TESTING (BOOL [OFF]): Enable CTest and build unit tests. Unit tests are located in “test” subdirectories, and can be executed with the ctest command.

BUILD_SAMPLE (BOOL [OFF]): Build sample code, such as sample channels, clients or servers.

Mac OS X Options

Mac OS X has specific options for 32-bit, 64-bit and universal binaries. By default, cmake will only build for the native architecture. Target architectures can be specified with the CMAKE_OSX_ARCHITECTURES option:

Where i386 is 32-bit, x86_64 is 64-bit. Specifying both 32-bit and 64-bit means building universal binaries.

WITH_SSE2 (BOOL): Build with SSE2 CPU instructions support (Intel architecture only).

WITH_NEON (BOOL): Build with NEON CPU instructions support (ARM architecture only).

WITH_CLIENT (BOOL [ON]): Build clients

WITH_CLIENT_CHANNELS (BOOL [ON]): Build client channels.

WITH_SERVER (BOOL [OFF]): Build servers

WITH_SERVER_CHANNELS (BOOL [OFF]): Build server channels.

WITH_CHANNELS (BOOL [ON]): Build channels.

• AUDIN (Audio Input)
• CLIPRDR (Clipboard Redirection)
• DRIVE (Drive / File System Redirection)
• DRDYNVC (Dynamic Virtual Channel)
• PARALLEL (Parallel Port Redirection)
• PRINTER (Printer Redirection)
• RAIL (Remote Applications)
• RDPDR (Device Redirection)
• RDPSND (Audio Output)
• SERIAL (Serial Port Redirection)
• SMARTCARD (Smart Card Redirection)
• TSMF (Multimedia Redirection)
• URBDRC (USB Redirection)

CHANNEL_ (BOOL): Build channels

CHANNEL_NAME_CLIENT (BOOL): Build client channel. This option is dependent on CHANNEL_.

CHANNEL_NAME_SERVER (BOOL): Build server channel. This option is dependent on CHANNEL_.

WITH_JPEG: Build with JPEG codec support. This feature is not part of the canonical RDP specifications, and is implemented as an alternative codec to RemoteFX or NSCodec.

WITH_WIN8: Build with Windows 8 support. This is used by the Windows FreeRDP server and enables linking against Windows 8 libraries, therefore breaking backwards compatibility.

CTest unit tests are located in “test” subdirectories and are deeply integrated with the rest of the CMake family of software process tools. CTest unit tests do not need a particular test framework. Test code is written as simple programs which return an exit code indicating success or failure.

CTest unit tests can be enabled with the BUILD_TESTING option.

All unit tests can be executed by invoking ctest with no option:

Unit tests can be filtered by name using a regular expression and the –R option.

To run all tests with a name beginning with “TestPath”, use:

To execute only the “TestPathCchAppend” test, use:

Debug output is turned off by default, but it can be enabled with the –V (verbose) option:

These instructions are preliminary for those who want to try FreeRDS as it is being developed.

Install the dependencies for FreeRDS as instructed in the FreeRDP section of this manual.

Clone the FreeRDP repository with the FreeRDS development branch:

Clone the FreeRDS development repository in the server directory of the FreeRDP source tree:

The FreeRDP git repository automatically ignores the server/FreeRDS directory, such that you can manage the two git repositories independently. Ignoring FreeRDS in the FreeRDP git repository prevents accidental commits where the FreeRDS sources would be included.

Follow the regular instructions for building FreeRDP, with the exception of a few extra options (WITH_SERVER, WITH_X11RDP). It is currently much easier to deploy FreeRDS to a temporary directory in order to execute it. For the purpose of this example, let’s use /opt/freerds as an installation prefix:

X11rdp is an alternative X11 server like Xvnc, Xephyr, Xnest and Xvb. Normally, these servers are built alongside Xorg with the xorg-server sources as they make use of internal APIs and libraries that are not installed. To build X11rdp, we need to build the xorg-server sources in a known directory such that we can include them in our cmake project.

The generic approach is to install all the distribution-provided packages required to build the xorg-server package from source. You can then obtain the distribution-sources for the xorg-server package or obtain vanilla sources corresponding to the same version. This process is automated with cmake build scripts, but needs to be done prior to generating the FreeRDS project:

If all goes well, you should have xorg-server built in external/Source/xorg-server. Create a symbolic link to that location from session-manager/module/X11/server/xorg-server:

session-manager/module/X11/server/xorg-server will then be picked up by the FreeRDS build system.

When generating project files with cmake, specify the prefix using -DCMAKE_INSTALL_PREFIX=/opt/freerds:

Then always execute «make install» after building and launch freerds from its installed location. Executing from the source tree may be properly supported in the future but for now it is not recommended.

On distributions with iptables (CentOS, etc), you can turn the firewall off for testing:

On distributions with UFW (Uncomplicated Firewall) such as Ubuntu and Linux Mint, you can allow port 3389:

Open two terminals logged in as root, and change directory to your installation prefix (/opt/freerds).

In the first one, execute freerds:

In the second one, execute freerds-session-manager:

There are easier ways of executing freerds but this manual execution method is more flexible for development purposes.

You can then connect locally:

Keyboard Type

Physical keyboard type used in Windows keyboard layouts. In the vast majority of cases, type 4 (IBM keyboard) is used. Keyboard type 7 (Japanese 109 keyboard) is used with Japanese keyboard layouts. Most other keyboard types are archaic and are most likely irrelevant today, like type 1 (Olivetti 102 keyboard). Complete keyboard type information also includes a keyboard subtype and number of function keys. Virtual scan code values used in RDP are relative to a specific keyboard type, which is in most cases, but not always, keyboard type 4. This means one should not create static keyboard maps directly involving virtual scan codes, since this approach ignores the keyboard type information and is therefore flawed by design for a minority of cases. Instead, developers are encouraged to create keyboard maps using virtual key codes, and generate on-the-fly a keyboard map to virtual scan codes using the winpr-input module.

Virtual Scan Code

A virtual scan code is a scan code corresponding to a physical key on a given keyboard type. A virtual scan code value ranges from 0 to 127 and is either extended or non-extended. Here are some sample mappings between a keyboard type, virtual scan code, and extended/non-extended flag to help understand the differences:

• (Type4, 0x1C, NonExtended) = VK_RETURN (regular Enter key)
• (Type4, 0x1C, Extended) = VK_RETURN (keypad Enter key)
• (Type4, 0x1E, NonExtended) = VK_KEY_A (physical ‘A’ key when using a qwerty layout)
• (Type4, 0x1E, Extended) = VK_NONE (no corresponding virtual key code)
• (Type7, 0x70, NonExtended) = VK_DBE_KATAKANA (special japanese key)
• (Type4, 0x70, NonExtended) = VK_NONE (no corresponding virtual key code)

Virtual Key Code

Windows virtual key codes are a keyboard-independent codes representing a keyboard key. They are not in any way representative of output characters that results from keyboard input. Not all virtual key codes are given names, and information about some of the less frequently used codes is spread out. For the sake of convenience, WinPR provides an exhaustive list of known virtual key codes in winpr/input.h. Since letter keys are not given official names, WinPR defines VK_KEY_LETTER, where each letter key matches the corresponding key on a US qwerty layout. This means that VK_KEY_Q (top left) is still VK_KEY_Q on an azerty keyboard, even if the corresponding physical key has the letter ‘A’ on an azerty layout. Mapping virtual key codes to corresponding output characters is the keyboard layout’s job.

Keyboard Layout

Keyboard layouts on Windows are implemented using DLLs which export some information about them (keyboard type information) and static data structures used for mapping virtual key code input to output characters. A keyboard layout is uniquely identified by an id, such as 0x00000409 for the US keyboard layout.

The process of mapping virtual key code input to output characters is a non-invertible function, meaning that output characters cannot be correctly mapped to the original virtual key code input without loss of information. For instance, the capital letter ‘A’ can be produced by pressing the ‘A’ key while the shift key is down, or when caps locks is toggled. Using only the output character ‘A’, it is impossible to know if the character was produced using the shift key or the caps lock key. The same problem occurs for cases for keys which do not directly produce output characters, such as the control or alt keys. With no output characters to try mapping to original virtual key codes, there’s not much that can be done. Other cases which prevent proper mapping of output characters to input virtual key codes are dead keys, or keys which do not result in a direct character output but affect the next key press. In many non-US keyboard layouts, accented letters are typed by first pressing a key corresponding to the accent and then typing the letter that needs to be accented. In theory, one can get by creating keyboard layout specific maps, but this is a tedious process that needs to be repeated for every keyboard layout in existence, while being broken by design.

WinPR (winpr-input module) offers reusable keyboard mapping utilities to help implementers with providing exhaustive, accurate keyboard support. Include winpr/input.h to make use of these.

To make debugging and parsing easier, functions are provided to match known key names to their numerical values:

Example: mapping XKB key name to virtual key code and printing out the conversion result:

Example: converting textual representation of a virtual key to its corresponding numerical value:

When mapping keyboard systems, the general approach is to create a map between the native key codes and virtual key codes. However, since RDP uses virtual scan codes, you will still need to map the virtual key codes to virtual scan codes before sending them. The advantage is that virtual scan codes are truly keyboard independent and have proper names, while virtual scan codes are highly impractical from the fact that they don’t really have names other than their number and are prone to change with regards to the physical keyboard type in use. If the only data you can have from the local input system is output characters, you should attempt using unicode input instead and limit usage of non-unicode keyboard input events to non-character input for keys like shift and num lock.

Example: mapping virtual key codes to virtual scan codes:

Example: mapping virtual scan codes to virtual key codes:

Certain keyboard systems use key codes which can be statically mapped to virtual key codes. WinPR currently provides mapping for Linux evdev and Mac OS X keycodes:

Most modern Linux X11 environments used evdev for input devices. The good news is that evdev uses a static set of X11 keycodes, which is not the case in other X11 environments. When evdev is not in use but XKB is available, a dynamic keyboard map can be generated on-the-fly using the XKB keyboard mapping utilities. One can use the xev utility to test keyboard input and see X11 keycodes. The following is a sample xev output for the ‘A’ key on a Linux system using evdev:

Example: mapping Linux evdev keycode to virtual key code back and forth:

Mac OS X uses the same set of keycodes in X11 and non-X11 environments. While values from 0 to 7 are unused, the keyCode member of the NSEvent class is off by 8. This means that when receiving the keycode value from Mac OS X, you should increment it by 8 before passing it to GetVirtualKeyCodeFromKeycode(), and decrement the keycode value returned by GetKeycodeFromVirtualKeyCode() before passing it to Mac OS X.

Example: mapping Mac OS X keycode to virtual key code back and forth:

An RDP synchronize event is used to synchronize keyboard toggle keys, such as caps lock and num lock. Synchronization of toggle keys is usually required whenever the local session window gains focus, as toggle key states may have changed while the window was not focused.

• KBD_SYNC_SCROLL_LOCK
• KBD_SYNC_NUM_LOCK
• KBD_SYNC_CAPS_LOCK
• KBD_SYNC_KANA_LOCK

Each flag should be set only if the corresponding key is toggled on the local keyboard. The Kana Lock key is only meaningful for Japanese keyboard input.

An RDP keyboard event is a message containing a Windows virtual scan code (extended or non-extended) along with flags to mark the corresponding key as being up or down.

• KBD_FLAGS_EXTENDED
• KBD_FLAGS_RELEASE
• KBD_FLAGS_DOWN

Keyboard Unicode Event

An RDP unicode keyboard event is a message containing a unicode character along with flags to mark the key as being released.

Example: sending ‘A’ unicode character:

An RDP mouse event is used for standard mouse buttons (left, middle and right), mouse movement and mouse wheel scrolling.

• PTR_FLAGS_DOWN
• PTR_FLAGS_MOVE
• PTR_FLAGS_BUTTON1 (left)
• PTR_FLAGS_BUTTON2 (right)
• PTR_FLAGS_BUTTON3 (middle)
• PTR_FLAGS_WHEEL
• PTR_FLAGS_WHEEL_NEGATIVE
• WheelRotationMask

Example: mouse left-click:

Example: mouse movement:

Example: mouse wheel scrolling:

Extended Mouse Event

An RDP extended mouse event is used for extended mouse buttons, such as button 4 and 5. The extended mouse event accepts the same flags as the regular mouse event, with a few extended flags.

• PTR_XFLAGS_DOWN
• PTR_XFLAGS_BUTTON1 (button 4)
• PTR_XFLAGS_BUTTON2 (button 5)

Example: extended mouse click

Virtual Channel API

VirtualChannelEntry is the entry point of static virtual channel clients. This function is called with a pointer to a CHANNEL_ENTRY_POINTS structure containing the portion of the virtual channel API exposed to the virtual channel client:

The data contained within this structure is only valid for the duration of the call to VirtualChannelEntry and should therefore be copied.

VirtualChannelInit has to be called by the virtual channel client when VirtualChannelEntry is called.

ppInitHandle receives the init handle which is used to identify the current connection when calling VirtualChannelOpen.

pChannel is an array of CHANNEL_DEF structures, where the number of elements in the array is given by channelCount.

VirtualChannelOpen should be called for each channel registered by the current virtual channel client when VirtualChannelInitEvent is called with a CHANNEL_EVENT_CONNECTED event.

VirtualChannelOpen takes the init handle obtained by a previous call to VirtualChannelInit and receives an open handle which will be used in calls to VirtualChannelWrite and VirtualChannelClose. A pointer to a VirtualChannelOpenEvent function is also passed to VirtualChannelOpen which will be used to receive notifications for read and write operations.

VirtualChannelOpenEvent is used to notify the virtual channel client of data being received or the completion of data write operations.

Virtual channel clients call VirtualChannelWrite with the open handle obtained by calling VirtualChannelOpen in order to write data to the virtual channel.

VirtualChannelClose is called by the virtual channel close using the open handle returned by the previous call to VirtualChannelOpen to close the virtual channel.

Источник