This article is part of the Perl Lazarus Project, an effort to make Windows GUI development in Perl practical again by identifying a working toolchain for creating, packaging, and distributing desktop applications.
The name is a nod both to Lazarus of the Bible and to the excellent Lazarus IDE for Free Pascal. Perl does not currently have a direct equivalent to that kind of unified rapid application development environment, so this project focuses on documenting a practical path using the tools that are available today.
This page is about installing wxPerl under Strawberry Perl for application development and distribution as a Windows executable.
This is a critical ability for any freelance Perl developer, since it complements a Perl journeyman's ability to do many things on servers, such as create remote services. Being able to transfer these skills to the desktop environment is especially useful on Windows, where users are accustomed to paying for software. In short, Perl programmers who want to make a living on their own need to know how to create and distribute Windows GUI applications; this page covers a large piece of how to do that.
wxPerl GUI running on Windows as a double-clickable EXE file! Created using wxGlade, a RAD-ish tool. See more images on Github.
Instructions are provided with the versions detailed below. If there are newer versions of any of the modules, you may try them out (of course); but understand they have not been tried and shown to work like the version combinations below.
Newer PDL-based build path. The PDL ZIP conventionally unpacks under C:\sw\pdl. Add C:\sw\pdl\c\bin, C:\sw\pdl\perl\site\bin, and C:\sw\pdl\perl\bin to the active PATH. This combination should be treated as experimental until the full build and packaging workflow is verified.
Read the script carefully before running it. As written, it installs portable Strawberry Perl, builds wxWidgets from source, manually installs Alien::wxWidgets configuration, then builds Wx. It does not use the PDL ZIP by default, so the script needs adjustment for the C:\sw\pdl PDL layout. It is best treated as an upstream build recipe or advanced helper, not as the primary beginner installation path.
wxGlade is a GUI builder for wxWidgets applications. It is written in Python, but critically supports outputting Perl code. It is actively developed, and the developer is very responsive on Github to bugs and feature requests. It is the closest thing we have in Perl to a rapid application development environment, in the spirit of Lazarus for Free Pascal.
Developers interested in earlier wxWidgets GUI builders and older Perl-capable tools can also see the longer list of RAD tools and GUI builders near the end of this page, including some useful but discontinued, archived, or historically important projects.
Last tested on 25 Jan 2025, although later versions of Python 3 were tested (specifically, 3.12.8), wxPython would install but not run wxGlade properly
install as admin (checkbox should be already checked; also opt'd to add "python" to the PATH)
Note: if this fails, you may need to reinstall pip; but it should be available in the CMD window. Based on experience, pip doesn't seem to be available via the Strawberry Perl terminal, so be sure to get a standard Windows CMD window to do this part.
This section outlines some different workflows that are found among members of the community who use wxPerl. Like any workflow, the based on level of experience and particular application.
Example layout with Strawberry Perl for running the application and Makefile, vim under MSYS2 for more streamlined workflow. wxGlade is under there, too; when there is a change to the GUI, the project is saved and code generated using "ctrl-g". vim is used to edit the code and will update whenever wxGlade updates it, if you do it right your custom code won't get clobbered.
The best way to recreate the "edit-run-fix" workflow of code editing enjoyed by vim users is to install MSYS2 and use its terminal to install both vim and git:
pacman -S vim git
Note: you do not want to run the Perl code generated by wxGlade inside of the MSYS2 terminal. When you install git, it will install its own perl and clobber Strawberry Perl in your PATH. Run the Perl code for your project from a Strawberry Perl terminal.
Just like the editor options in Windows is not ideal, neither are the Git options (GH's "Git for Windows" is exceptionally awkward to use, not sure how to it is possible to be good in "Windows" tbh; YMMV.) Under MSYS2's terminal, you may install git and use it as you may be accustomed on Linux. You may want to generate an ssh-key, which will be vailable in `~/.ssh/` by default. So you can do all the normal git workflow stuff from there once your key is created and added to your Github keyset.
Pro Tip: Turn Off MSYS2's vim Mouse Support and Auto/Smart Indenting
wxGlade has some settings that tells it to not overwrite changes you made in the output Perl script, but beware - this option is not on by default. That means that means that your file will get overwritten if you tell wxGlade to generate new code again. The general workflow is as follows:
start a new project (or open an existing one)
click on the root "Application" object in the object viewer
find the output pane, set the output to be "Perl"
set version of wxWidgets to be "3.0"
Recommended settings for using wxGlade for Perl development.check "Keep user code", this will make sure wxGlade doesn't overwrite code that is outside the bounds of very clearly marked blocks in the code
Using wxGlade's "Separate file for each class" Option
This section is more of a work in progress since a reliable method of distributing single file executables (or developing installation packages for Windows) is still an open question, there is hope that this will end up being a relatively smooth process. Needless to say, it is critical for Perl developer to be able to distribute Perl based GUI applications as single file (.exe) or via installation on Windows. The client should NOT need to be running through any of the instructions above to run a program that you would like to sell them for actual money.
Below are the initial instructions for generating an EXE file. There are also many ways that wxPerl developers go about doing, based on their use case and experience.
PAR::Package, App::PP::Autolink, and Wx::Perl::Packager
Note: pp_autolink, provided by App::PP::Autolink, has proven to be absolutely critical to finding the required DLLs that need to be added manually to the wxpar command below via the --link flag.
Earlier versions of wxGlade introduced an improper idiom at the bottom of the generated Perl script that caused a problem when running via a PAR::Packed executable. TLDR: remove the "unless(caller)" block and just run the Wx event loop unfettered. For more information, please read the PAR::FAQ.
Earlier versions of wxGlade also used a non-Exporter import tag that wxpar could not properly follow; see the code "before" and "after" below:
use Wx qw[:allclasses];
use strict;
...
package main;
unless(caller){
my $local = Wx::Locale->new("English", "en", "en"); # replace with ??
$local->AddCatalog("app"); # replace with the appropriate catalog name
my $app = MyApp->new();
$app->MainLoop();
}
Should be modified to look like the following:
use Wx;
use strict;
...
package main;
my $local = Wx::Locale->new("English", "en", "en"); # replace with ??
$local->AddCatalog("app"); # replace with the appropriate catalog name
my $app = MyApp->new();
$app->MainLoop();
See this Github issue for wxGlade, where both were fixed. At the time of this writing, the changes have not been put out in an official release; but they are applied in the master branch.
(copied from the Makefile) - Note, mentions using App::PP::Autolink to suss out required DLLs (provides pp_autolink, which helped!)
all:
wxpar --verbose -o ./dist/nhc-explorer.exe -l c:/strawberry/c/bin/libcrypto-3-x64__.dll -l c:/strawberry/c/bin/zlib1__.dll -l c:/strawberry/c/bin/libssl-3-x64__.dll ./asgs-storm-bug.pl --gui
wxpar --verbose -o ./dist/DEBUG-nhc-explorer.exe -l c:/strawberry/c/bin/libcrypto-3-x64__.dll -l c:/strawberry/c/bin/zlib1__.dll -l c:/strawberry/c/bin/libssl-3-x64__.dll ./asgs-storm-bug.pl
# It was an adventure finding all the dependencies related to the wxpar command,
# particularly those around what was needed. The basic process entailed:
# 1. use wxpar, which generates an options file with all the Wx DLLs
# 2. install App::PP::Autolink, which provides the utility "pp_autolink"; this
# utility scans the .pl file you're packing, in this case, "asgs-storm-bug.pl",
# for DLLs - lo' and behold, it found the ones I needed; in particular the critical
# one that was not getting picked up by pp or wxpar, "libcrypto-3-x64___.dll!"
# 3. run the "wxpar" command above
# 4. test in a non-Strawberry Perl window, such as the MSYS2 terminal, using the command:
#
# PERL_DL_DEBUG=5 dist/nhc-explorer.exe
#
# I learned about this command while searching, here:
#
# https://stackoverflow.com/questions/423330/why-cant-dynaloader-pm-load-ssleay-dll-for-netssleay-and-cryptssleay
It is worth repeating that pp_autolink, provided by App::PP::Autolink has proven to be absolutely critical to finding the required DLLs that need to be added manually to the wxpar command below via the --link flag.
If you are having problems finding all the DLLs (some which may not be obvious until the EXE generated is tried on a different machine,) you need to give pp_autolink a shot.
Martha - A lightweight wxPerl helper for packaging Perl applications on Windows
In February 2026, an exciting new project was launched to help Perl programmers bootstrap creating Windows executables and program installers. Martha, formerly referred to here as wxPerl Helper, is designed to work within the development environment described herein (Strawberry Perl, Alien::wxWidgets, wxPerl, wxGlade). Given this environment, the current "beta" version of the software can assist with the following:
automatically finds required DLLs
generates Makefile, based on using wxpar (a pp wrapper)
user can tweak and save the Makefile
user can load an existing Makefile
user can run the Makefile to create the executable
user can run the executable
user can configure an Inno Setup provided it is installed
run the Inno Setup file to generate an installer for their program
finally, they may test the installer directly from the GUI
Martha is targeting the gap that exists for a user that is able to generate Perl code from wxGlade, but then is unsure how to actually distribute their application in the way Windows users expect.
For more information and updates on the project, visit the Github repo here.
For historical context on earlier Perl/wxWidgets GUI builders, RAD tools, and discontinued Windows application-building efforts, see Perl and wxWidgets RAD on Windows.
A possible "old school" approach, may be to use Office'97 Office Developer Edition (ODE) - via Access'97 there is an installer builder - this is a last resort and still needs to be verified to work for non-Access distributions
Inno Setup (github) - Inno Setup is a free installer for Windows programs by Jordan Russell and Martijn Laan. First introduced in 1997, Inno Setup today rivals and even surpasses many commercial installers in feature set and stability.
This section briefly describes using Inno Setup to build an installed for a Windows executable. It seems to be pretty easy to use and has support for many more things than most Perl programmers may actually need. One important thing to note is that it is free for non-commercial use, there is a commercial license required by the author for using this to distribute commercial programs. The license is one-time and entitles the end-user to 2 years of updates. After that, they may continue to use it but will not receive the updates. For all intents and purposes it is a one-time fee, and may considered worth it for some software authors.
Using Inno Setup consists of creating a configuration file, then using the Inno Setup Compiler's GUI to open up an ".iss" file, then run it interactively. It may also be run on the command line or as part of a Makefile.
Click here to see an example configuration file used by the NHC Advisory GUI.
Support for creating configurations and installers with Inno Setup is also being included in Martha, the wxPerl helper application being created as part of this Perl Guilds effort to make it easier for traditional Perl programmers to break into the world of commercial Windows GUI programs.
The following sections are "works in progress," and remain open questions (for this author anyway). Contributions to develop these sections are greatly appreciated, but not expected. Over time I will update these sections as I learn more about using wxGlade and Perl on Windows.
While wxpar does indeed create EXEs that can run on Windows machines that do not otherwise have any required libraries on them, I have found some early problems that are most likely due to lack of experience in this area. An understanding of this area is forthcoming.
XRC is a language agnostic and XML based way of describing the GUI layout for wxWidgets. It appears to be the right way to maintain the GUI layout of your production grade program, while maintaining the set of Perl handlers in your own source tree. Think of XRC as the separation of the controller and view in MVC - it to GUI programming what templates are to web application programming. It seems that as one advances his skills in this area, he will want to use XRC. The benefit also of this is that one may be able to create controllers in multiple languages rather than tie the GUI construction in Perl or some other language exclusive - of course, wxGlade can output in different languages, but none is as abstract as XRC.
Wx::Demo example of loading an XRC file; wxGlade can output directly to XRC, which can then be read in Perl. This is how.
Wx::Demo has a few good examples of running XRC applications; wxGlade can output XRC, but it is not aware of any language bindings or drivers for it.
Experience with managing XRC files may allow us as Perl programmers to use RAD tools and GUI builders that were not intended to support wxPerl, but can output XRC files. DialogBlocks is such a professional and commercial GUI builder for wxWidgets, and it is actively maintained.
This great, but out of print wxWidgets book is available for free (PDF) at https://wxwidgets.org/docs/book/. It mentions wxPerl and has an index of tools and programs that any wxWidgets programmer may find interest.
Cross-Platform GUI Programming with wxWidgets (free PDF!!) by Julian Smart and Kevin Hock (with Stefan Csomor) is an old, but nice resource to have. It mentions wxPerl quite a bit and has a nice index of tools to help the wxWidgets GUI programmer, regardless of the language they are using. In particular, "Appendix E: Third-Party Tools for wxWidgets" is a very interesting read.
