This topic contains recommendations on developing applied solutions operating under Windows OS and Linux OS.
When you work with files in Linux, you should remember that file and directory names are case-sensitive. For example, files named file.txt and File.txt are different files that may be located in the same directory.
In Linux the concept of drives, which is actively used in Windows, does not exist. Linux has the root file system ("/") generally used to mount other file systems located on other media (drives and partitions, flash drives, ISO-files, etc.). The most frequently used (though optional!) locations for mounting external media are the mounting points (directories) /mnt or /media. When you mount external media, they can be mounted as /media/<Partition label> or /media/<Device ID>. Automatically mounting an external medium cannot be guaranteed.
Not assigning a drive letter in Linux may cause the following problems:
Applied solution uses explicit paths oriented to Windows only;
Applied solution uses path check mechanisms that verify drive letter assignment, among other things;
When you specify a path starting from the root directory, you should remember that in Linux this path expressly identifies the directory or file location, whereas in Windows it does not. For example, the path \temp\file.txt (/temp/file.txt in Linux) points to the exact file location and name in Linux: it is a file named file.txt and located in the temp directory of the root file system. In Windows OS identification is not unique. This path indicates that a file named file.txt is located in the temp directory of the root directory on the current drive. Moreover, the current drive may be different for two subsequent launches of the same client application with the same infobase.
When you develop applied solutions, you should remember that Windows and Linux use different path separators. Windows uses "\" ("back slash"), whereas Linux uses "/" ("forward slash"). If you work with the 1C:Enterprise script methods, you do not have to take this difference into account, since these methods work correctly with any separator. However, if you need to pass the path to an external application, you should enter the path separators used in the operating system where 1C:Enterprise is running. You can obtain information on path separators using the following functions: GetPathSeparator(), GetClientPathSeparator(), GetServerPathSeparator().
In addition to using different path separators, Windows and Linux process file masks differently. For example, the *.* mask indicates retrieval of all files in Windows and retrieval of all files containing the period (".") in their names in Linux. This difference may cause the 1C:Enterprise script methods FindFiles(), DeleteFiles() and the FileDialog object to behave in unexpected ways. The specifics of using file masks in different operating systems are described in the Syntax Assistant for FindFiles() and DeleteFiles() functions. You can obtain a file mask retrieving all files using the following functions: GetAllFilesMask(), GetClientAllFilesMask(), GetServerAllFilesMask().
In addition, in Linux you cannot access network resources using UNC notation (in this case, an address would look like: \\server\folder\folder\file.ext). Therefore, if you need to use an external network resource, you should first mount it to the root file system. You should also remember that you can use a different mounting point (directory) every time. You can also access external network resources using special applications (such as smbclient), but you should remember that these applications may be missing in the installation of Linux you are using.
For more detailed information about the Linux file system and how to use it, see the Linux documentation or internet resources.
External devices are named (and accessed) differently in different operating systems. For example, serial ports in Windows are named COM1, COM2, etc. In Linux (depending on the distribution kit and the device) ports may be named: /dev/ttyS0, /dev/ttyS1, etc. or: /dev/ttyUSB0, /dev/ttyUSB1, etc. You should keep this in mind when you develop both add-ins working with devices and add-in settings dialogs. For example, obtain a list of ports that can be specified in a data processor directly from the add-in you set up using a special method.
In general, the super-user account (root) is not used in Linux. The end-user can only save files to the home directory and the temporary files directory. The rest of the file system may either be available in read-only mode or be unavailable (whether the entire system or just certain directories). Therefore, at the development stage you should take into account which access privileges will be granted to the user who will run 1C:Enterprise for directories returned by global context methods:
DocumentsDir() – read and write access
BinDir() – read access
TempFilesDir() – read and write access
UserDataWorkDir() – read and write access
To access external devices, the user might be required to join a specialized group (or groups). For further details, see the documentation for the operating system you use.
When you develop applied solutions, it is recommended you always use style fonts without explicitly specifying the typeface. If required, you can use fonts included in Microsoft Core Fonts (http://sourceforge.net/projects/corefonts/). We recommend that you do not use other fonts in applied solutions, as these fonts may be unavailable in some operating systems, and the appearance of the applied solution would be distorted.
In 1C:Enterprise running on Linux, WebKit is used to work with HTML. In 1C:Enterprise running on Windows, the current version of Internet Explorer is used to work with HTML. Therefore, you should remember the following when you work with HTML:
An HTML document can be displayed differently in different operating systems.
If you access the DOM-model of an HTML document using the HTMLDocumentField.Document property, you should only use properties and methods available in all web browsers that are supported by 1C:Enterprise. This is both due to the use of various tools for displaying HTML documents in client applications as well as due to the fact that web access may be used to work with the applied solution, increasing the number of web browsers and their versions.
In Linux these mechanisms are unavailable. Use alternative tools for integration, such as file exchange in XML format or web services.
If your add-ins are based on COM technology, we
recommend that your redesign them using NativeAPI.