{"id":986,"date":"2026-03-08T11:46:24","date_gmt":"2026-03-08T19:46:24","guid":{"rendered":"https:\/\/www.installaware.com\/blog\/?p=986"},"modified":"2026-10-28T20:46:06","modified_gmt":"2026-10-29T04:46:06","slug":"a-case-study-in-porting-from-delphi-to-lazarus-arm64-diskzips-shell-extensions","status":"publish","type":"post","link":"https:\/\/www.installaware.com\/blog\/?p=986","title":{"rendered":"A Case Study in Porting from Delphi to Lazarus ARM64: DiskZIP’s Shell Extensions"},"content":{"rendered":"\n

Having waited for almost ten years for Delphi’s ARM64 <\/strong>Windows compiler, we threw in the towel and sponsored Lazarus<\/strong>‘s ARM64 <\/strong>compiler:<\/p>\n\n\n\n

www.installaware.com\/lazarus-arm64.msi<\/a> (or download www.installaware.com\/lazarus-arm64.exe<\/a> should you fancy a direct executable instead of a network deployable MSI file)<\/p>\n\n\n\n

For several years now, Free Pascal<\/strong>‘s ARM64 <\/strong>support had almost worked, with only a few outlier issues that resisted resolution. InstallAware<\/strong> kept prodding and prodding, and the community delivered! That’s the power of open source. You can read about my initial reactions here:<\/p>\n\n\n\n

Lazarus for Windows on aarch64 (ARM64) – Native Compiler<\/a><\/p>\n\n\n\n

TLDR; this post describes some of the problems we came across while porting our product from Delphi to Lazarus<\/strong>, specifically with a view towards how we resolved them. If you, like us, need true ARM64 <\/strong>support from Delphi and are tired of waiting – read on! This guide is intended for an audience that is totally new to Lazarus<\/strong>, and we hope to ease your pain with all we’ve learned.<\/p>\n\n\n\n

ARM64 is NOT ARM64EC<\/strong><\/p>\n\n\n\n

Sadly, I must stress that ARM64EC is absolutely useless for anyone who actually needs a true ARM64 <\/strong>compiler. Even if ARM64EC code is comprised of “pure” ARM instructions, the binary format results in ARM EXEs that can load x64 DLLs, or ARM DLLs that can be loaded from x64 EXEs. Sure, the code that runs may be “pure” ARM, but it’s useless for all scenarios that actually require a true ARM64 <\/strong>compiler – of which we had one in our hands: Shell Extensions<\/strong>.<\/p>\n\n\n\n

Shell Extensions<\/strong> are DLLs loaded by Windows File Explorer. Explorer is a true ARM64 <\/strong>process – it’s not an ARM64EC or x64 or x86 process. This means if you try to load an ARM64EC DLL into Explorer, that’s absolutely no different than trying to load an x64 DLL, or an x86 DLL into Explorer. It just won’t work. And you might think – like I did – that it defeats the purpose of having an ARM compiler at all!<\/em><\/p>\n\n\n\n

Why We Needed True ARM64 for DiskZIP’s Shell Extensions<\/strong><\/p>\n\n\n\n

You’re already familiar with Shell Extensions<\/strong>, even if you don’t think you are.<\/p>\n\n\n\n

Context Menus<\/strong><\/p>\n\n\n\n

You work with these, literally every day. Any time you right-click in Windows File Explorer, you’re basically working with Context Menu <\/strong>Extensions:<\/p>\n\n\n\n

\"Context<\/figure>\n\n\n\n

A real quick, brief sidebar here: While we certainly did port DiskZIP’s Context Menu<\/strong>‘s to ARM64<\/strong>, this was perhaps the most useless part of the exercise. Context Menu<\/strong> Extensions, as you already know, are so prevalent and ubiquitous! Windows actually supports loading x86 and x64 extensions inside the ARM64 <\/strong>version of File Explorer through various compatibility shims. This means the process isn’t perfect, but here is where a true ARM64 <\/strong>compiler does add the least value to the equation.

You might also be familiar with how most Context Menus<\/strong> are nowadays hidden inside Windows 11’s higher level menus:

\"Windows

We can’t take credit for this implementation, either. That was handled by the InstallAware<\/strong> team, and their truly magical Context Menu Bridge:<\/strong>

InstallAware Context Menu Bridge – InstallAware<\/a>

To get your stuff showing inside this top-most level Windows 11-only menu, you actually have to do three things:

1) Write a different type of Shell Extension that’s NOT a Context Menu<\/strong> Extension
2) Build a Sparse MSIX<\/strong> package for it, and get it code signed (or Windows refuses to load it)
3) Automate the installation and removal<\/strong> of this Sparse MSIX<\/strong> package

Just to get on the new Windows 11-exclusive menu. Yes, it’s torture. That’s why InstallAware<\/strong>‘s Context Menu Bridge<\/strong> is a lifesaver, but that’s a topic for another post.<\/p>from InstallAware Context Menu Bridge – InstallAware<\/a><\/cite><\/blockquote><\/figure>\n\n\n\n

Copy Hooks<\/strong><\/p>\n\n\n\n

So you’re already familiar with right-clicking to create archives on Windows, who isn’t? But did you know that with DiskZIP, you can create new archives out of existing folders by just adding an archive extension to your desired folder?<\/p>\n\n\n\n

\"Copy<\/figure>\n\n\n\n

Isn’t that fun? The technical name for the type of shell extension that makes this possible is a Copy Hook Extension<\/strong>. It triggers when some file – or folder – is being copied, moved, or renamed – our extension fires on renames when it detects you’re using an archive file extension that is supported by one of its installed plug-ins: It blocks the rename, and compresses the chosen folder instead (leaving its original contents intact, of course).<\/p>\n\n\n\n

And of course, all shell extensions we describe from here onwards, including the Copy Hook Extension<\/strong>, require true ARM64 <\/strong>compiler outputs. ARM64EC won’t work (so sadly, the upcoming Delphi won’t cut it). ARM64 <\/strong>Windows won’t emulate x86 or x64 shell extensions for Copy Hooks<\/strong> or anything else I’ve written about below.<\/p>\n\n\n\n

Tool Tip Handlers<\/strong><\/p>\n\n\n\n

Here’s another fun one. Just hover your mouse over a file type, and get a customized textual preview of its contents – all dished up by the custom code running in your shell extension:<\/p>\n\n\n\n

\"Tool<\/figure>\n\n\n\n

Property Sheet Handlers<\/strong><\/p>\n\n\n\n

Did you know you can actually tap into the File Properties window shown by Windows File Explorer? Yup, that’s just another type of shell extension:<\/p>\n\n\n\n

\"Property<\/figure>\n\n\n\n

Drag and Drop Handlers<\/strong><\/p>\n\n\n\n

You know, like when you drag files on top of an existing archive – and it adds the files into the archive.<\/p>\n\n\n\n

\"Drag<\/figure>\n\n\n\n

Shell Namespace Extensions<\/strong><\/p>\n\n\n\n

The name’s a mouthful for sure, but this is the best we saved for last:<\/p>\n\n\n\n

\"Shell<\/figure>\n\n\n\n

You’re basically tapping into File Explorer’s tree, your code injecting virtual folders inside a given file type (such as an archive). You’re also injecting your own Lazarus <\/strong>(formerly Delphi) window directly inside File Explorer’s right pane, the contents of which you control exclusively. It’s a bit of rocket science to get it working right, honestly!<\/p>\n\n\n\n

And yes, for all these things – you need true ARM64 <\/strong>– or File Explorer just won’t play ball, at all.<\/p>\n\n\n\n

Porting Challenges<\/strong><\/p>\n\n\n\n

So Lazarus ARM64<\/strong> definitely proves itself by being able to port a full-blown shell namespace extension from Delphi, and run it successfully under Windows File Explorer. But how did we get there, how hard was the journey?<\/p>\n\n\n\n

It’s a lot easier than you think, actually. Here’s our findings, with shoutouts included for the best practices!<\/p>\n\n\n\n

Start With Lazarus’s Own Import Process<\/strong><\/p>\n\n\n\n

You’re not the first one looking to bring over code and projects from Delphi, and it shows. Click Tools | Delphi Conversion<\/strong> on the main Lazarus <\/strong>menu. Choose Convert Delphi Project to Lazarus Project<\/strong> for the most comprehensive solution. Sometimes it helps to move over units (and forms) individually, for which you’d go with the Convert Delphi Unit to Lazarus Unit<\/strong> menu item.<\/p>\n\n\n\n

Best practice:<\/strong> Always do the conversion on a copy of your projects folder, instead of the original project folder.<\/em><\/p>\n\n\n\n

You can generally accept the defaults for the conversion. Lazarus<\/strong>‘s default conversion process takes care of most of the grunt work in getting started for you – such as adding in a vital Lazarus<\/strong>-only units that you may not already know about, which comes in especially handy when this is your first time using Lazarus<\/strong>.<\/p>\n\n\n\n

Activate ARM64<\/strong><\/p>\n\n\n\n

Edit:<\/mark> The steps below are required only<\/mark> when you’re using the 32-bit Lazarus IDE.<\/em><\/strong><\/p>\n\n\n\n

After the original publishing of this article, the Lazarus team built a native ARM64 IDE<\/mark>, along with a native ARM64 debugger<\/mark><\/em>.<\/strong> This IDE cannot run on AMD\/Intel platforms, so we updated our installer to seamlessly install the original 32-bit IDE on AMD\/Intel<\/mark>, and to install the native ARM64 IDE on Snapdragon\/nVIDIA AI PC\/”Apple Silicon”<\/mark>.<\/em><\/strong><\/p>\n\n\n\n

This way, even if you don’t own an ARM64 device, you can still develop for ARM64 by doing what’s called cross-compilation<\/mark><\/em><\/strong>. The steps below activate this convenient cross-compilation option, which was all we had when this article was first published:<\/em><\/strong><\/p>\n\n\n\n

Follow these steps to enable the ARM64 <\/strong>compiler sponsored by InstallAware<\/strong>:<\/p>\n\n\n\n

    \n
  1. On the main Lazarus <\/strong>menu, click Project | Project Options<\/strong>. Then choose Compiler Options | Config and Target<\/strong>.<\/li>\n\n\n\n
  2. In the Target platform<\/strong> box, inside the Target OS<\/strong> field, choose Win64<\/strong>.<\/li>\n\n\n\n
  3. Inside the Target CPU<\/strong> family field, choose aarch64<\/strong>.<\/li>\n<\/ol>\n\n\n\n

    If your project is a DLL<\/strong>, Lazarus <\/strong>will now place it inside the lib\\aarch64-win64<\/strong> folder of your main project folder.<\/p>\n\n\n\n

    For executables, the outputs are found inside your main project folder.<\/p>\n\n\n\n

    Now the real fun begins \ud83d\ude00<\/p>\n\n\n\n

    When Projects Fail to Convert<\/strong><\/p>\n\n\n\n

    It’s not a bad idea to create them from scratch. Simply start with an empty Lazarus <\/strong>project:<\/p>\n\n\n\n

      \n
    1. On the main Lazarus <\/strong>menu, click File | New<\/strong>. Then choose Project | Application<\/strong> to start with a new GUI app.<\/li>\n\n\n\n
    2. On the main Lazarus <\/strong>menu, click Project | Project Inspector<\/strong>. Right click “unit1.pas<\/strong>” and choose Remove<\/strong>.<\/li>\n\n\n\n
    3. Manually convert all your units one by one using the Convert Delphi Unit to Lazarus Unit<\/strong> option.<\/li>\n\n\n\n
    4. Add them in to your new Lazarus <\/strong>project using the Project Inspector<\/strong>.<\/li>\n\n\n\n
    5. If you have any custom code in your DPR <\/strong>project file, paste it into its Lazarus <\/strong>equivalent in the LPR <\/strong>file.<\/li>\n\n\n\n
    6. If you have any custom defines in your Delphi <\/strong>project settings, add them in to your Lazarus <\/strong>project:
      a. On the main Lazarus <\/strong>menu, click Project | Project Options<\/strong>. Then choose Compiler Options | Custom Options<\/strong>.
      b. In the Custom <\/strong>options box, type each define you have in your Delphi <\/strong>project using the form “-dDEFINE<\/strong>“, separating them with a space.<\/li>\n\n\n\n
    7. If your project references units in source paths, add them in with these steps:
      a. On the main Lazarus <\/strong>menu, click Project | Project Options<\/strong>. Then choose Compiler Options | Paths<\/strong>.
      b. Add each path to the Other unit files<\/strong> and Include files<\/strong> fields, separating paths using a semicolon “;<\/strong>“.<\/li>\n<\/ol>\n\n\n\n

      This approach works really well with projects that don’t convert over well for whatever reason.<\/p>\n\n\n\n

      When Forms Fail to Convert<\/strong><\/p>\n\n\n\n

      In our real world experience, forms that had multiple nested controls didn’t port over too well. Also problematic was image data, which was sometimes encoded differently by Delphi. Re-creating complex form layouts can be a pain, so don’t despair and give these suggestions a try instead – pre-processing misbehaving forms using Delphi, before you feed things over to Lazarus<\/strong>.<\/p>\n\n\n\n

      Best practice:<\/strong> Delete all image data, saving all image content to temporary files first. You can always load them right back into your Lazarus <\/strong>form after the initial conversion.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> Delete all controls that you don’t already have installed on the Lazarus <\/strong>component palette. Alternately, you can take to AI (Claude seems to work well enough) to port over the components over to Lazarus <\/strong>first, which is also an effective strategy.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> Feed your forms directly to AI (again, Claude was what we used), asking it to convert from Delphi to Lazarus<\/strong>. Sometimes when there’s no obvious cause for failure, this gets you over the conversion hurdle.<\/em><\/p>\n\n\n\n

      Touching Up Converted Units<\/strong><\/p>\n\n\n\n

      So you’ve got your project file (LPR<\/strong>) and your forms (LFM<\/strong>) converted over – congrats! Now it’s time to touch up the units themselves.<\/p>\n\n\n\n

      Best practice:<\/strong> Always add in Windows <\/strong>to your uses<\/span> clause. Chances are it was already there, but removed by Lazarus <\/strong>during conversion.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> If you’re working with GUI projects, also add in the Interfaces <\/strong>unit to the first line of your project file (LPR<\/strong>)<\/em>‘s uses<\/span> clause, assuming it wasn’t there already<\/em>.<\/p>\n\n\n\n

      Best practice:<\/strong> Again for GUI projects, be sure to add in the LCLIntf<\/strong>, LCLType<\/strong>, and LMessages<\/strong> units to the uses<\/span> <\/strong>clauses of your form unit files (PAS<\/strong>) – chances are they’re there already, but we’ve seen them go missing every now and then.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> Add the define {$mode delphiunicode} <\/strong>immediately after your unit name declaration, especially if you’re wanting Unicode<\/span> support in Lazarus<\/strong>. This define is the closest to what we get with Unicode Delphi.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> Manually replace all ANSI Windows API references with Unicode<\/span> Windows API references. This is necessary because Lazarus <\/strong>defaults to ANSI versions of the Windows API. For example, replace CopyFile with CopyFileW<\/strong>, MoveFile with MoveFileW<\/strong>, etc. Most of the time, simply adding W <\/strong>to the end of the Windows API being rejected by the compiler because of string type mismatches works fine.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> The above applies to not just function names, but also to record names. For example, not only would you need to rename the ShellExecuteEx function to ShellExecuteExW<\/strong>, but also the record it uses from SHELLEXECUTEINFO to SHELLEXECUTEINFOW<\/strong> – the former just resolves to SHELLEXECUTEINFOA in Lazarus<\/strong>, which will get you stuck in ANSI-land.<\/em><\/p>\n\n\n\n

      Best practice:<\/strong> For undeclared APIs, structures, constants, etc. ask your favorite AI for Lazarus <\/strong>declarations designed to work with the {$mode delphiunicode}<\/strong>, or just copy them over from the Delphi “headers” for the Windows API:<\/em><\/p>\n\n\n\n

        \n
      1. In your Delphi IDE, right-click the declaration and choose “Find Declaration<\/strong>” in the popup menu.<\/li>\n\n\n\n
      2. Copy the constants\/records right on over.<\/li>\n\n\n\n
      3. Where record fields involve string types, make sure to explicitly convert them to Unicode<\/span> strings for Lazarus<\/strong>. For example, a record field which reads LPCSTR would have to become LPCW<\/strong>STR in Lazarus <\/strong>for proper Unicode<\/span> support.<\/li>\n\n\n\n
      4. Where declarations involve functions, you may need to also press Ctrl + Shift + Down Arrow<\/strong> to navigate to the portion of the unit which declares the external DLL it is imported from – you’ll want to copy over both the function prototype and its external DLL reference to your Lazarus <\/strong>unit.<\/li>\n\n\n\n
      5. We worked a lot with COM interfaces, this being a Shell Extension<\/strong> undertaking; and found that interfaces were sometimes defined differently as compared to Delphi: Lazarus <\/strong>would complain that interfaces which we already implemented were somehow missing. In these cases, it was easiest to:
        a. Right-click the interface, for example IContextMenu<\/em>, and choose “Find Declaration of IContextMenu<\/strong>“. Note that you do this in the Lazarus <\/strong>IDE (and not in Delphi), seeing as you need to access how Lazarus<\/strong> defines the interface.
        b. Copy over all the function prototypes into your own COM Object’s interface declaration, and of course also update the function signatures in your implementations of those functions to the Lazarus <\/strong>way of declaring things.
        c. While you’re at it, make sure you’re using the right interface – adding a W <\/strong>where necessary to the interface name.<\/li>\n\n\n\n
      6. When parameter types change in function declarations, it is simply a matter of fixing code that calls those functions. For instance, where Lazarus <\/strong>expects the address of a variable, instead of the variable itself; just adding an “@<\/strong>” in front of the variable name pleases the compiler. The underlying APIs and function calls are all the same, it’s just about formatting the code to suit how it’s all ben declared, as it were.<\/li>\n\n\n\n
      7. Last but not least, it is worth mentioning that some declarations may reside inside different units in Lazarus<\/strong>. You can always ask your favorite AI to see if it knows (if it’s hallucinating about the unit, chances are you’ll have to declare things yourself). I’ve also seen where ANSI functions\/records are declared in Lazarus<\/strong>, but their Unicode<\/span> counterparts are not – so it’s up to you again.<\/li>\n<\/ol>\n\n\n\n

        This is literally the entire gamut of the grunt work that Lazarus <\/strong>could not automate for us. We didn’t use AI for it, although you could certainly try and see how much you can get away with it?<\/p>\n\n\n\n

        Odds and Ends<\/strong><\/p>\n\n\n\n

        So since we’re building shell extensions, our projects never had a predefined TApplication<\/em> object. In Delphi, you can create a form without having an owner TApplication<\/em>, but if you try this in Lazarus<\/strong>, it’ll crash everything swiftly. The cure is mind numbingly simple. Just make sure you use this code before creating any stand-alone forms you may have in your DLLs (admittedly, this may not apply to you):<\/p>\n\n\n\n

        MyApp := TApplication.Create(nil);
        MyApp.Initialize;<\/em><\/p>\n\n\n\n

        Certain function names may also conflict between Lazarus <\/strong>class libraries and Windows – for us, TRTLCriticalSection<\/em> and its associated function calls was one of these. Simply prefixing “Windows.<\/strong>” to all mismatched references (in both functions and data types) sorts this problem in no time at all, without having to rewrite your code to use Lazarus<\/strong>‘s library functions instead.<\/p>\n\n\n\n

        Touching Up Project Settings<\/strong><\/p>\n\n\n\n

        So you’ve imported your project, forms, and units – and even gotten them to compile – great job!<\/p>\n\n\n\n

        One of the best surprises of Lazarus <\/strong>is after you manage to get things to compile, everything just works, exactly as it used to \ud83d\ude42<\/p>\n\n\n\n

        After all, you’re literally porting to a dialect of the same language – and almost the same class library – we deserve this break, don’t we?<\/p>\n\n\n\n

        Debugging<\/strong><\/p>\n\n\n\n

        Chances are by the time you’re reading this, Lazarus <\/strong>will already have a debugger for ARM64 <\/strong>– but as the earliest of the early adopters here, we weren’t as fortune.<\/p>\n\n\n\n

        Edit:<\/mark> Indeed, now we have an invaluable, native ARM64 debugger!<\/mark><\/em><\/strong> The steps below would be required only if you’re running the 32-bit Lazarus IDE on an AMD or Intel device<\/mark>.<\/em><\/strong> Debugging automatically works on the ARM64 Lazarus IDE<\/mark>, even including support for attaching to external processes<\/mark> for DLL debugging (which comes in very handy when you’re debugging shell extensions, and need to attach to explorer.exe).<\/em><\/strong><\/p>\n\n\n\n

        For those edge cases which must absolutely have troubleshooting help with a debugger, it helps to revert your project settings back to defaults, so you can step through your code line by line:<\/p>\n\n\n\n

          \n
        1. On the main Lazarus <\/strong>menu, click Project | Project Options<\/strong>. Then choose Compiler Options | Config and Target<\/strong>.<\/li>\n\n\n\n
        2. In the Target platform<\/strong> box, inside the Target OS<\/strong> field, choose (Default)<\/strong>.<\/li>\n\n\n\n
        3. Inside the Target CPU<\/strong> family field, choose (Default)<\/strong>.<\/li>\n<\/ol>\n\n\n\n

          Now you can debug easily in the Lazarus <\/strong>IDE!<\/p>\n\n\n\n

          Of course, when you’re done testing, be sure to change your settings back to ARM64<\/strong>.<\/p>\n\n\n\n

          Also, keep in mind that some issues might only surface with an ARM64 <\/strong>target.<\/p>\n\n\n\n

          Don’t be shy to ask AI if you’re ever stuck and need further help!<\/p>\n\n\n\n

          Build and Enjoy<\/strong><\/p>\n\n\n\n

          You’ve done it!<\/p>\n\n\n\n

          That wasn’t too bad, was it? We got everything done – for our extremely complicated shell namespace extension code – in just about a week’s time! I’m betting most of your projects would be done in an hour, or a day tops \ud83d\ude42<\/p>\n\n\n\n

          You can take a look at our own work by installing DiskZIP from www.installaware.com\/diskzip.exe<\/a> – thanks to its intelligent InstallAware<\/strong> setup, it’ll seamlessly install the ARM64 <\/strong>components when you run it on an ARM64 <\/strong>device (such as native ARM <\/strong>Microsoft Surface<\/em> hardware, or virtualized Windows 11 running on Parallels <\/em>on your Apple Silicon device), while installing x86 or x64 components when you run it on other kinds of (virtualized) hardware – all from a single installation binary.<\/p>\n\n\n\n

          Now that your code is compiling under Lazarus<\/strong>, you’re basically one step away from compiling it natively for macOS and Linux, too! That’s exactly what we did some time ago, bringing InstallAware<\/strong> to Macintosh and GNU\/Linux worldwide.<\/p>\n\n\n\n

          But that’s a topic for another blog post \ud83d\ude09<\/p>\n\n\n\n

          John Gaver
          for InstallAware<\/strong> Skunkworks<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

          Having waited for almost ten years for Delphi’s ARM64 Windows compiler, we threw in the towel and sponsored Lazarus‘s ARM64 compiler: www.installaware.com\/lazarus-arm64.msi (or download www.installaware.com\/lazarus-arm64.exe should you fancy a direct executable instead of a network deployable MSI file) For several years now, Free Pascal‘s ARM64 support had almost worked, with only a few outlier issues … <\/p>\n

          Continue reading “A Case Study in Porting from Delphi to Lazarus ARM64: DiskZIP’s Shell Extensions”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-986","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/986","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=986"}],"version-history":[{"count":23,"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/986\/revisions"}],"predecessor-version":[{"id":1044,"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/986\/revisions\/1044"}],"wp:attachment":[{"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=986"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=986"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.installaware.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=986"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}