Cross Platform Perl Programming

Perl was originally written for Unix, and some of its features are specific to that operating system. In this course we will do our best to avoid those features or at least draw attention to the places where they are necessary. But Perl is not tied to Unix. Currently there are precompiled Perl distributions available for most common platforms, including the big three: Unix, Macintosh, and Windows.
Question: Is Perl a cross platform programming language?
Answer: Yes, Perl is a cross-platform programming language, which means that Perl code can run on multiple operating systems such as Windows, macOS, and Linux, without any modifications. This makes it an attractive choice for developers who need to write code that can run on a variety of systems, as well as for system administrators who need to write scripts that can be run on different types of servers.

1. Support for the Tk interface to Perl became available for the Win32 port. Tk is a GUI widget toolkit that comes from the UNIX world, where it was the Delphi-like rapid application development tool for the X Window system. If you think it is hard to program graphics in Windows, X is worse than you could ever imagine. Before Tk, no real alternative to low-level C code existed for GUI development. Tk is of interest both to transplanted UNIX developers, who already know it, and to people who want to create cross-platform GUIs. The material on developing GUIs using Automation servers is still of interest to Windows programmers, however, because Tk is likely going to have a learning curve, and Visual C++ is likely already to be well known.
2. Although I do not discuss XS in this course, and I say XS is harder to learn from scratch, do not get the idea that I am knocking it. I am constrained by time and space to talk about things that have not been talked about elsewhere. The XS interface is finally becoming fairly well documented, and if you need to learn it, you can pick it up. XS is a viable alternative and may be the best alternative in many instances, especially if you have C code you want to compile and embed in Perl on many different platforms. XS is actually an interface (somewhat similar to IDL) for defining the "glue" between a Perl module and an extension library. You need to learn this extension language and write all the glue code yourself. With Automation, Perl's Win32::OLE module has prewritten glue for the Perl side, and Visual C++ automates generation of the glue on the C++ side. For the programmer who wants to knock out code fast, Automation requires less work.
3. If you would like more information, be sure to get a good course (see Bibliography) that discusses how COM specifically works with the registry, not just how to tweak user interface settings in the registry.
4. If you do not know what a GUUID, it is not important. See an advanced course such as Box's Essential COM for details. This discussion is for the enlightenment of COM programmers getting into Perl.
5. One of the remaining problems with object-oriented programming in general is that different people still call the same idea by different names, which makes writing a course that uses mixed languages difficult.
6. I am reminded of a mainframe programmer who was told the 6 byte restriction on symbols in the assembler had been relaxed in a new version.
7. By this qualification I mean that UNIX, and all OSes after it (Windows, OS/2, etc.), have used C as their systems programming language. All interfaces are defined in terms of C, and all other languages tend to go along with it because they have to. Now, with C++, this is not the case. All systems programming interfaces are either still defined in C, or, for Windows at least, are being redefined in terms of COM.

At the most basic level, all windowing platforms (Apple Macintosh, X Windows, and Microsoft Windows) are very simple. They provide a low-level API to create and manage windows, to report interesting events such as mouse and keyboard events, and to draw graphical elements such as lines, circles, and bitmaps. The problem is that drawing even a simple form takes a considerable amount of code and reading thousands of pages of documentation. Often-used patterns of GUI code have evolved into widgets (called "controls" in the Microsoft Windows world); examples include

1. buttons,
2. scrollbars, and
3. listboxes.

Building a GUI is now a simple matter of launching an interactive form designer and dragging and dropping these ready-made components into a layout of your choice. Object-oriented programming has never been easier. It turns out that widgets and scripting languages are a perfect match. Widgets have simple interfaces, and form-based GUIs are not performance-critical. Both of these attributes make GUIs a very fertile ground for scripting. Combine that with the fact that GUIs need the most configurability (because that's the part of the application the user deals with, and for the most part, the GUI is the application), and you can understand the enormous popularity of tools such as Visual Basic, PowerBuilder, and Hypercard. On Unix systems, X Windows has been the windowing platform of choice. Several widget toolkits have been built over X: Athena, InterViews, Motif, and Tk. For professional good looks, ease of use, and documentation, you can't beat Tk. To top it all, it is free! Unlike other widget toolkits, Tk was developed expressly to be driven by a scripting language: Tcl.
Indeed, it can be argued that Tk is the chief reason for Tcl's popularity. There are a lot of people who don't like Tcl as a scripting language but love Tk, and have attempted to adapt it to their favorite scripting language:

1. Scheme,
2. Python,
3. Guile and
4. Perl.

Malcolm Beattie made the initial attempt to provide a Perl layer that internally used the Tcl interpreter to reach the Tk library.

Click the link below to take a quiz with respect to the cross platform features of Perl.
Cross Platform - Quiz
A current listing of available platforms is available on the Perl.Com Web site.