Any builtin way to access pointer offset of compressed files in a compiled installer?

To explain what I want, here's a NSIS code excerpt:

    goto SKIP_OGG_EXTRACT

    SetCompress off

    File "YS100_44.ogg"

    File "YS101_44.ogg"

    File "YS102_44.ogg"

    File "YS103_44.ogg"

    File "YS104_44.ogg"

    File "YS105_44.ogg"

    File "YS106_44.ogg"

    File "YS107_44.ogg"

    File "YS108_44.ogg"

    File "YS109_44.ogg"

    File "YS110_44.ogg"

    File "YS111_44.ogg"

    File "YS112_44.ogg"

    File "YS113_44.ogg"

    File "YS114_44.ogg"

    File "YS115_44.ogg"

    

    File "YS134_44.ogg"

    File "YS135_44.ogg"

    File "YS137_44.ogg"

    File "YS138_44.ogg"

    File "YS139_44.ogg"

    File "YS140_44.ogg"

    File "YS141_44.ogg"

    File "YS142_44.ogg"

    SetCompress auto



SKIP_OGG_EXTRACT:

Let's say I compile 50 megs of OGG files. I don't need them compressed under lzma as that'll waste time, they're already compressed audio files. So I used the "SetCompress off" as one should.

The problem comes when it's time to not just extract, but decode/unzip back to WAVE format with the OGG-to-WAVE decoder NSIS plug-in that I built with the 2018 source code of OGG/Vorbis...

What I did in the past is inefficient, extract the OGG from the installer to the final location, and then pass the filename to the decoder to convert it to wave... So 50 megs of OGG data that are already sitting in the installer exe, are needlessly written again to the final location, when if I could just get a pointer offset into the installer EXE, I could just make the OGG decoder read the data from there, and open a wave file to the final location to begin decoding...

In other words, I wanna skip the inbetween step of normal extraction of the OGG files, I wanna get the offset of each OGG as it's been compiled in the installer exe, give that offset to my plugin DLL to open or reuse the existing handle, to read the OGG data directly to begin decoding it to wave in the final location, does that make sense ?

To this effort, I did start disassembling a compiled installer exe, I found where the NSIS code opens a file handle to itself, and unzips a file list to extract the OGG files, but I still need more research time on how this is arranged...

I have my own ideas on how to get this done, but I don't wanna waste my time if there's already a built-in way to do this, hence the thread.

Does that make sense, have I explained what I wanna do here ?

Any protip/help would be appreciated, thanks!

This is such a special case, you will have to add support for it in your plug-in. Perhaps you can take a look at 7-zip, it knows how to decompile NSIS installers.

Ah darn, so there isn't a built-in way, so be it. Understandable, I figured as much, but I wanted to be sure.

Yeah, you're right, if I just grab the basic 7Zip API and open the installer EXE as an archive, it can obtain a file index/manifest with name, size, offset per the screenshot below. Exactly what I need!



So with just the basic 7Zip API, minus any codec algorithms, just the file archive analysis code, I should be able to get this done and still keep my plug-in DLL compact.

I've been using NSIS since 2004 BTW having started out as an InstallShield specialist when I began IT work in 1998 (Gained about 3 years of experience with it). My licensing had expired, so I wanted freeware circa 2004-2005 and a friend showed me NSIS, been using it ever since! A simple example is this installer I made for a small typing tutor videogame.

Anyway, thanks!

NSIS also allows you to append data to the end of the .EXE, you could do this in !finalize by calling a custom application. Just append the data and at the end append some sort of offset table. You can then use the NSIS file functions to read from $ExePath.