Developing A Game Engine with Perl: Part 5 - 32bit -> 64bit & Perl's Storable
Tags: perl, gamedev, linux, devjournal
Published: 2021-12-01 03:14:32

[If you haven't heard already...](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-part-2-mouse-input-43nj) **I DO NOT KNOW WHAT I AM DOING.**

If you want to start reading from the beginning. Check out the [first article in this series](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-3b8)

Continuing on with the [last article](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-part-4-uefi-vs-opensuse-installer-5e1c) let's talk about changing system architecture and how that can affect Perl code, specifically [Storable](https://perldoc.perl.org/Storable).

- Mouse Input Support
- Hardware Failure
- Server Upgrade
- UEFI vs OpenSuSE Installer
- **32bit -> 64bit & Perl's Storable**

After the old server had [HDD failures](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-part-3-hardware-failure-server-upgrade-on1) and finally [managing to upgrade](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-part-4-uefi-vs-opensuse-installer-5e1c) to the new server, I eagerly began getting all the services and software installed to test the engine on new hardware. I was quickly meet with an error I have never seen before.

`Byte order is not compatible at /usr/lib/perl5/5.34.0/x86_64-linux-thread-multi/Storable.pm`

After doing some quick reading, I came to understand that Perl uses architecture specific ways to save content to files when using Storable. Specifically if you use `lock_store` and `store`. These are part of Perl's core system and what I use throughout the engine for working with the file structure.

I had to carefully re-read the perldoc's to discover that you can avoid architecture incompatibility by simply using `nstore` and `lock_nstore` The method you use for retrieving the stored files doesn't matter, only when storing the data into files does it matter.

I tried to find ways of being able to convert the stored files from 32bit architecture to 64bit, but ultimately the only real option was to use the old server to re-store the files with lock_nstore.

Luckily the old PC was still working, and I was able to modify the code and re-store all the files. The change and usage was simple:

I had to change my use statement from:
`use Storable qw(lock_store lock_retrieve);`
to
`use Storable qw(lock_nstore lock_retrieve)`

And to re-store I changed my code from this:
`lock_store($data_ref, $dir_location);`
to
`lock_nstore($data_ref, $dir_location);`

Have you ever had to write code for architecture compatibility? Or fix code migrated from one architecture to another? What do you prefer for storing data to files in Perl?

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action. 

[ANSI Game Engine on Instagram](https://www.instagram.com/ANSIGameEngine/)
[ANSI Game Engine on Facebook](https://www.facebook.com/ANSIGameEngine)

[Prev << Part 4 - UEFI vs OpenSuSE Installer](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-part-4-uefi-vs-opensuse-installer-5e1c)
[Next >> Part 6 - A Colourful Telnet Server](https://dev.to/ansigameengine/developing-a-game-engine-with-perl-part-6-a-colourful-telnet-server-4i7g)

Cheers!
Shawn