Me and the old DELL are ready to test anything you can come up with.
(Preferrably relating to hiding GPT partitions, of course.)
Good , but I don't know if I can trust you
No, seriously, the batch right now is essentially read-only (though in latest incarnation it leaves the 34 sectors loaded into (md)0x300+34), so it is basically "safe" (though as said leaves memory drive "dirty").
At this point what I would do (had I available a suitable testing platform) would be to make a modified batch, let's say GPTcrc32nl.g4b without the initial loading of the sectors from disk and re-using those copied to memdrive, and start experimenting, finally reversing the modifications by issuing manually the "opposite" of the initial loading, i.e. if you ran (say) the:
the batch will execute initially:
dd if=%source% of=(md)%sect_md%+%sect_num% bs=512 count=%sect_num%
dd if=(hd0)0+34 of=(md)0x300+34 bs=512 count=34
which you can invert by issuing:
dd of=(hd0)0+34 if=(md)0x300+34 bs=512 count=34
with this command the modified sectors in (md) will be written back to disk.
Of course if there is a mistake in either the theory (the idea of limiting the partitions number) or in the practice (the modifications made) the result will be an unbootable disk (and no way back).
So, if you have:
1) an "expendable" USB stick
2) a dd image of it stored on some other media
3) the possibility of booting to grub4UEFI from the stick on your Dell computer
4) the possibilty of continuing booting to a PE or a Windows installation (residing on the internal disk)
then you can proceed.
The theory is as follows:
1) it seems that Windows based tools (but it has to be checked) default to make a EFI PART setup with 128 entries (128 bytes each) for partitions, these leads to the famous 32 sectors (LBA 2-33)
2) the specifications use a field (at offset 0x50 on sector LBA 1) that defines the amount of partiton entries
3) as well the specifications have a field (at offset 0x28 on sector LBA 1) that defines the first available sector for actual partitions (this is normally set to 34 for the reasons above BUT *any* GPT partitioning tool would normally have first partition at LBA 2048) most probably - but has to be verified - this is only precautionary (i.e. you can reduce the number of available partitions from 128 to - say - 4, leaving this field set to 34 or 0x22).
4) I have no idea if modifications to the EFI PART sector and/or to the partition array need to be reflected on their backup copy (at the end of the disk) i.e. whether a booting OS will "trust" the modified first few sectors (as long as the CRC32 checksums are valid) or if it will override them with the backup sectors (or viceversa it will automatically fix the backup sectors) or *whatever else*, so in order to make valid tests it might be needed to change not only the "main" but also the "backup"
The practice would be more or less *like*:
1) make a disk with 4 partitions
2) verify that it works and all drive letters are assigned/all 4 partitions are visible, etc.
3) change the EFI PART at 0x50 from 128 (0x80) to 4 (0x4)
4) change the first crc32 to reflect this change
5) repeat tests in #2, nothing should have changed
6) copy last (fourth) partition entry (last 128 bytes of LBA 3) to the fifth position (first 128 bytes of LBA 4)
7) 00 out fourth partition entry (write 128 00's to last 128 bytes of LBA 3)
8) change both the crc32's to reflect the change
9) repeat tests in #2 this time the fourth partition should have "vanished"
10) change the EFI PART at 0x50 from 4 (0x4) to 5 (0x5)
11)change the first crc32 to reflect this change
12) repeat tests in #2, situation should be back as in #2 and #5
13) copy third partition entry (128 bytes at offset 256 on LBA 3) to the sixth position (offset 128 on LBA 4)
14) 00 out third partition entry (write 128 00's at offset 256 of LBA 3)
15) change the EFI PART at 0x50 from 5 (0x5) to 6 (0x6)
16) change both the crc32's to reflect the change
17) repeat tests in #2, situation should be back as in #2 and #5 and #12
18) change the EFI PART at 0x50 from 6 (0x6) to 4 (0x4)
19) change the first crc32 to reflect this change
20) repeat tests in #2, now you should only be able to see the first 2 partitions.
We have to understand if all (or only part) of these is possible:
1) have "holes" in the partition table (it should be possible because it is what should happen when you delete a partition)
2) have partition entries in an order different from actual physical order/position on disk
3) whether the second crc32 checksum is intended by Windows and by other OS's as extending to only the present/defined in EFI PART partition entries or if it extends to sectors occupied by them (in other words whether the checksum in #16 above should be about 6 entries (128*6=768 bytes) or about 2 sectors or 1024 bytes.
It's a lot of testing, prone to errors and with possible roadblocks at each step that I cannot foresee, how to workaround them (if any) needs to be found out "on the spot".
 you need to edit the current version of the batch to calculate the crc32 on ONLY the sectors (or partition entries) used in the area between
crc32 (md)%sect_md%+%sectlen% | set crc_part=0x