Skip to content

SoftEther VPN Developers Guideline

Daiyuu Nobori edited this page Jan 14, 2019 · 6 revisions

SoftEther VPN's guidelines for developers Version 2019/01/14

New contributions are subject to the following guidelines:

  • MUST support both UNIX and Windows.

  • MUST support both GCC and Microsoft Visual C++. Do not use any syntax or functions which cause compile errors. Using macros to achieve compatibility with both compilers is OK.

  • MUST support Microsoft Visual C++ 2008, because it's the latest version which can compile binaries compatible with Windows 9x and Windows NT 4.x.

  • MUST support GCC 2.x. Some users need to compile binaries for specific Linux embedded hardware, for which cross compilers are only GCC 2.x.

  • MUST use C language. Do not use C++ language except for very limited cases (e.g. need to call Win32 COM API functions).

  • MUST support OpenSSL from version 1.0.2 to the latest.

  • MUST support all operating systems which are listed on http://www.softether.org/3-spec#Requirements. Cross platform compatibility must always be maintained. Please do not break compatibility with Windows 9x / NT 4.0. There are some users still using SoftEther VPN on these legacy OSes for industrial purposes (e.g. control systems).

  • MUST keep backward and upward compatibility with SoftEther VPN Stable Edition.

  • MUST NOT remove any features currently present with the default configuration settings. It is OK to add an opt-out configuration to turn off a specific feature in the configuration file.

  • MUST support configuration files saved by previous versions of SoftEther VPN.

  • MUST NOT add any new external programs / libraries dependencies. Please keep in mind the principle that SoftEther VPN doesn't depend on any external dependencies except for a few exceptions.

  • MUST NOT add any memory / resource leaks.

  • MUST support both IPv4 and IPv6 in new features.

  • MUST NOT remove IPv6 support.

  • MUST NOT add any crash / bug / vulnerability.

  • MUST NOT add any copyright-infringed / patented contents.

  • MUST perform defensive programming as much as possible.

  • MUST NOT change the existing working code unnecessarily. Keeping the code in a working state is the most important thing. If you want to add new features, adding small amounts of code to call new functions is OK. If you want to fix any existing problems, modifying the smallest amount of code is OK. In other cases you must keep the existing working code, in order to avoid breakages as much as possible.

  • MUST NOT change either the behavior or the arguments of the Mayaqua library's functions which are called in two or more forked repositories. In case only the arguments are changed, you may add a wrapper function to retain compatibility. If the behavior is changed, please create a new function.