Lessons Learned

What Started the PowerShell Compact-Archive Tool

When I was working on the Alphecca project, I realized I needed to add some assets to help create the atmosphere I envisioned. To do this, I needed a compiler - again. I had already developed the Bootless Star tool, but I didn’t really want to use it. Instead, I decided to experiment with creating a new compiler tool. It would be better, newer, and offer a chance to learn something on my own-and I thought it would be fun as well.

Why use the PowerShell Language

I did some reading about what PowerShell could do, using my mobile while walking around my college campus. I looked into its features: Can it compile zip files? Yes. Does it support Object-Oriented Programming? Yes. Does it have an IDE or some glorified text-editor environment? Yes and Yes. Does PowerShell have long-term viability on Windows? I wasn’t sure at the time, though this was before I discovered PowerShell Core. I wanted to use something that required less programming and fewer dependencies compared to Windows Batch, and PowerShell seemed to have what I was looking for at the time. Most importantly, I wanted a language where scripts were open for anyone to modify for whatever purpose, and where everyone can trust the program.

Why the Name 'PowerShell Compact-Archive Tool'

I wanted to include 'cat' in the name, somehow and in some way. The program's primary goal is to compact files into an archive data file, and this program is essentially a tool - 'CAT.' Adding 'PowerShell' in the name signifies that this program uses the PowerShell terminal. And so, I give you the PowerShell Compact-Archive Tool (PSCAT).

Why Development Lingered

Self-reflection on my part, blunt answer - I kept moving the goalposts. I managed this project through feature creep and shifting targets. I never explicitly set a hard line for what needed to be done and how to get there. Perhaps that was due to my lack of real Software Engineering experience, but also because I knew I could do anything I wanted. After many years of working on this tool, cramming as many features as I could, I realized I had forgotten why I created this tool in the first place. A co-worker was leaving the company to chase his dream of becoming a Game Developer, and hearing him talk made me remember the other projects I’d wanted to work on but had held myself back from-purposely, because of PSCAT. I needed that co-worker to chase his dream so I could realize that I had lost track of mine.

What are the Workarounds in PowerShell Compact-Archive Tool

Starting off, Windows PowerShell, compared to PowerShell Core, has Object-Oriented Programming (OOP) features that seem somewhat incomplete. Windows PowerShell's OOP has extremely harsh limitations that make it not very friendly to work with at all-whereas PowerShell Core's OOP is less restrictive, as long as you follow POSH semantics. Additionally, PowerShell doesn’t support 'Private Members' or 'constant types' in classes. Everything is wide open for all objects to manipulate, which makes it harder to prevent other objects from inadvertently changing a value when the member variable should remain unchanged. The only way to create constant values is through New-Variable - great for global variables or Procedural-Oriented Programming (POP), but an absolute nightmare for Object-Oriented Programming.

Shifting towards strange bypasses to get PSCAT to work on everyone's machines. How does one execute the PowerShell program? By default, when someone executes a PowerShell script (ps1 file) through the Windows GUI, the file extension by default-opens in Notepad.exe. It doesn't make sense to tell the user to open a PowerShell terminal and execute the program by following a detailed step-by-step guide, nor to configure the file in the Windows Control Panel or Windows Metro Control Panel. Moreover, the default value of the Execution Policy is set to 'Restricted,' meaning it’s not possible to execute any PowerShell scripts unless someone is willing to configure the Execution Policy using the Set-ExecutionPolicy cmdlet. An average Windows user will understandably not go through this trouble. Furthermore, in order to include libraries in PowerShell's instance environment, this cannot be done in the same script but must be handled through a different script. I have no answer as to why Microsoft designed it this way, and I gave up trying to understand their logic. Fortunately, however, with my past experience with Windows Batch through Bootless Star, I wanted the user to just click and go-exactly what I aimed for in PSCAT. The Bootstrap Windows Batch script was created to perform the following: the user clicks the batch script, which then executes the PowerShell instance and configures it. Everything works for the user; just get out of the way and let them do what THEY want with the program, full stop. PowerShell has some great advantages over Windows Batch, but Microsoft seems determined to stifle how PowerShell works within the Windows operating system.

Where PowerShell Compact-Archive Tool Stands

Because of Microsoft's decisions with Windows 11 and their vision for the future, I find myself not aligned with their direction. So much so that I moved towards the GNU/Linux ecosystem, which turned out to be the best decision for my sanity. To push PSCAT to the final finish line, I had to use a hypervisor with Windows 11 - yet even on a powerful system, that operating system feels dreadfully slow and bloated with unnecessary junk that hinders my productivity. I highly encourage anyone to fork this project and improve upon it; where I couldn't add in the additional features, someone else can.

What Features Should be Added

Here is a list of features I would encourage someone to implement if continuing onward with PSCAT’s codebase:

1. Cross-Platform Support
   PSCAT has some ability to work across multiple platforms, but it’s not complete. With the codebase reduction that occurred in the late stages of version 1.2.0, it should be easier to accomplish now. A good starting point might be with CommonCUI-review the existing functions and then look at the Load Project functionality. From there, you’ll see where to make modifications.
2. Windows Toast Notifications
   PSCAT previously had support for BurntToast, and I highly recommend using it again. It was removed because it became difficult to support with the Project Manager (which was also removed) in the late stages of 1.2.0. If I were to continue, I would bring this feature back, but would also need to reintroduce the CommonPowerShell class.
3. Git-SCM Support
   In previous versions of PSCAT, Git-SCM was supported, but I removed it in the late stages of 1.2.0. I wanted to shift to using PowerShell Modules to assist the user without requiring them to install additional dependencies. This would also help lighten the codebase by letting the modules do more for PSCAT without requiring hand-holding with the executable. Please keep security in mind.
4. 7Zip Support
   Similar to Git-SCM, 7Zip was supported in earlier versions but was removed in the late stages of 1.2.0 for the same reasons.
5. Adding PowerShell Modules (for features 2, 3, and 4)
   If you decide to incorporate the PowerShell Modules for features 2, 3, and 4, I would highly encourage using the CommonPowerShell static class. This class may need further improvements, but it offers an easy way to install and update modules. It was included during 1.2.0 but was removed in later developments.
6. Complex Builder Support for projects that do not conform to ZDoom's filesystem structure out of the box.
   While I don’t know of any ZDoom projects that don’t conform to the typical ZDoom PK3 filesystem structure, TGRDM3 is organized differently, and I wanted to establish a way for files to be organized in that structure. The Complex Builder would be a configurable script (or potentially a graphical window) where the user could define where specific assets should go within the PK3 structure.
7. Ability to compile ACS\BCC scripts
   This feature would allow PSCAT to compile ACS (Action Code Script) and BCC scripts, expanding the tool's utility.