Little tool to mark QB64 compiled EXE's with it size, for appending data.

[Dav]

This is something I've been using to help with appending data to my EXE's.  Seems to work with no problems, thought I'd share it.  It basically marks the EXE with its EXE file size, so my program can read that info and know where the appended data begins.  It shortens "This program cannot be run in DOS mode." to "This program can't run in DOS mode.", and uses the gained spaces to save the EXE size.

It works for me in QB64-32bit compiled programs.  Have not tested it in 64-bit at all.  Use at your own risks, as it overwrites EXE data. 

Mark your EXE's BEFORE you append data to it.

- Dav

Code: QB64: [Select]

1. '===============
2. 'MarkExeSize.bas
3. '===============
4. 'Marks QB64 compiled EXE's with its EXE data size.
5. 'Coded by Dav, JAN/2021
6.  
7. 'WINDOWS ONLY!
8.  
9. 'This helps facilitate using appended data on the EXE.
10. 'It saves the compiled EXE size to the EXE file, so
11. 'the program can read that info and jump to its data.
12.  
13. 'It does this by borrowing some space near the top of
14. 'the EXE file.  It shortens 'This program cannot be run
15. 'in DOS mode.' to 'This program can't run in DOS mode.' and
16. 'uses those 4 gained spaces to save EXE file size instead.
17.  
18. '=======================================================
19. 'Example...after you mark your EXE file, it can do this:
20. '=======
21. 'OPEN COMMAND$(0) FOR BINARY AS 1  'Open itself up...
22. 'test$ = INPUT$(200, 1) 'grab a little info
23. 'place = INSTR(1, test$, "This program can't") 'look for words
24. 'IF place = 0 THEN PRINT "No data found.": CLOSE: END
25. 'grab exesize info...
26. 'SEEK 1, place + 35: ExeSize& = CVL(INPUT$(4, 1))
27. 'Go there....
28. 'SEEK 1, ExeSize& + 1   'where appended data begins
29. '=======================================================
30.  
31. 'NOTE: Always mark the EXE before appending data to it.
32. '      If you use EXE compressors, like UPX, mark the EXE
33. '      AFTER using UPX, not before, otherwise the info won't
34. '      be read correctly by your program.
35.  
36.  
37. SCREEN Pete
38.  
39. PRINT
40. PRINT "================"
41. PRINT "MarkExeSize v1.0 - by Dav"
42. PRINT "================"
43. PRINT
44.  
45. IF COMMAND$ = "" THEN
46.     INPUT "EXE to Mark -->", exe$
47.     PRINT
48. ELSE
49.     exe$ = COMMAND$
50. END IF
51.  
52. IF exe$ = "" THEN END
53. IF NOT _FILEEXISTS(exe$) THEN
54.     PRINT "File not found.": END
55. END IF
56.  
57. OPEN exe$ FOR BINARY AS 1
58.  
59. 'find location of place to mark
60. test$ = INPUT$(200, 1)
61. place = INSTR(1, test$, "This program can")
62. IF place = 0 THEN
63.     PRINT "This file is not markable."
64.     CLOSE: END
65. END IF
66.  
67. 'jump to location
68. SEEK 1, place
69. look$ = INPUT$(19, 1) 'grab a little info
70.  
71. SELECT CASE look$
72.     CASE IS = "This program cannot"
73.         'mark/overwrite exe file info file with new info
74.         PRINT "Marking file "; exe$
75.         PRINT
76.         PRINT "EXE files size:"; LOF(1)
77.         PRINT "Data start loc:"; LOF(1) + 1
78.         new$ = "This program can't run in DOS mode." + MKL$(LOF(1))
79.         PUT 1, place, new$
80.         PRINT: PRINT "Done."
81.     CASE IS = "This program can't "
82.         PRINT "EXE already appears to be marked."
83.         PRINT
84.         SEEK 1, place + 35: datastart& = CVL(INPUT$(4, 1))
85.         PRINT "EXE files size:"; LOF(1)
86.         PRINT "Data start loc:"; datastart& + 1
87.         PRINT "Size of data  :"; LOF(1) - datastart&
88.     CASE ELSE
89.         PRINT "EXE is not markable."
90. END SELECT
91.  
92. CLOSE
93.  

[SMcNeill]

When I append data to the end of an EXE, I always just count backwards from the length of the data.

For example, I have a CSV text file.  I’d open the EXE, append the data to the end of it, and then write the length of that file as a 4-byte long.

Then, when I need to read that file, I read the last 4 bytes to get the size, then back up that length from the end, and get the data.

GET #1, LOF(1) - 4, data_length
File_data$ = SPACE$(data_length)
GET #1, LOF(1) - 4 - data_length, file_data$

Another file would just go after, with its length after that, until I stored all the files I wanted attached to the EXE.

[Dav]

Yea, that works great too.  I use that way also, when doing one file simple things especially. I have a couple of projects that used a lot of files, so i stored the file pack header and filesize lacation, so went with this way to be more organized.  But your way is the short and sweet method for sure.

Didnt you do a fireside animation with appended data once?

- Dav

[SMcNeill]

Yea, that works great too.  I use that way also, when doing one file simple things especially. I have a couple of projects that used a lot of files, so i stored the file pack header and filesize lacation, so went with this way to be more organized.  But your way is the short and sweet method for sure.

Didnt you do a fireside animation with appended data once?

- Dav

This one: https://qb64.freeforums.net/thread/32/campfire-demo  ;)

It’s also how my singing Christmas tree demo works too.  Song and image are appended to the end of the EXE.

[NOVARSEG]

GET #1, LOF(1) - 4, data_length
File_data$ = SPACE$(data_length)
GET #1, LOF(1) - 4 - data_length, file_data$

If a picture file, say, BMP was appended this way it could be saved once again as a BMP file and then use _LOADIMAGE. Yes I know of the other way using base 256 / 64  or base 256 / 128 conversion and storing the data in the BAS file.

It would be nice if QB64 had an instruction that would load a picture file from memory.

So you start with an BMP file appended to an EXE. From there get appended data into some kinda MEM block that returns a handle and then use PUTIMAGE etc.

[Pete]

ROFL @ SCREEN Pete

SCREEN Pete, the only screen mode anyone would ever need!

Pete :D

[Dav]

@Pete:  :)

@NOVARSEG:  Yes, that's an option.  I made a tool for doing that as well, saving and putting mem block images to the EXE.  Only downside is that the data is very large in size.  Here's the code I first came up with before adapting the loader code to load from EXE attachment instead.  These saves/loads external files.

- Dav

This one saves the image to a memdata file, it's width, height, data, and byte size.

Code: QB64: [Select]

1. INPUT "IMAGE File to load --> ", IN$
2. INPUT "IDATA file to save --> ", OUT$: IF OUT$ = "" THEN END
3. 'Load image file to screen mode
4. SCREEN _LOADIMAGE(IN$, 32): SLEEP 1
5. wid = _WIDTH: hih = _HEIGHT
6. DIM m AS _MEM: m = _MEMIMAGE(0)
7. INDATA$ = SPACE$(m.SIZE)
8. _MEMGET m, m.OFFSET, INDATA$
9. INDATA$ = _DEFLATE$(INDATA$)
10. SCREEN 0
11. OPEN OUT$ FOR OUTPUT AS 2
12. PRINT: PRINT "Saving image data to file...";
13. total& = 4 + 4 + 4 + LEN(INDATA$) + 4
14. PRINT #2, MKL$(wid) + MKL$(hih) + MKL$(LEN(INDATA$)) + INDATA$ + MKL$(total&);
15. CLOSE 2
16.  

This one loads it back...

Code: QB64: [Select]

1. INPUT "ID File to show --> ", IN$
2. IF IN$ = "" THEN END
3. OPEN IN$ FOR BINARY AS 1
4. SEEK #1, LOF(1) - 3
5. total& = CVL(INPUT$(4, 1))
6. SEEK #1, LOF(1) - total& + 1
7. wid = CVL(INPUT$(4, 1))
8. hih = CVL(INPUT$(4, 1))
9. idlen = CVL(INPUT$(4, 1))
10. INDATA$ = INPUT$(idlen, 1)
11. INDATA$ = _INFLATE$(INDATA$)
12. CLOSE 1
13. image& = _NEWIMAGE(wid, hih, 32)
14. DIM m AS _MEM: m = _MEMIMAGE(image&)
15. _MEMPUT m, m.OFFSET, INDATA$: _MEMFREE m
16. SCREEN _NEWIMAGE(wid, hih, 32)
17. _PUTIMAGE (0, 0), image&
18. SLEEP

[Dav]

I want to add that Steves way has a great advantage of not being restricted to windows only. So if your projects is for other platforms too, just forget this tool and use the saving a footer method.

- Dav

[NOVARSEG]

Can you do something like

DIM handle as long

DIM m AS _MEM: m = _MEMIMAGE(0)    (example from your code)

or


DIM m AS _MEM:    _MEMIMAGE(handle) = m   ?

I'm trying to create a handle from a memory block. I think there has to something more generic like

handle =_HANDLE(m)

or skip the handle altogether because  m has been dimensioned in memory. So there does not have to be a handle for m because the OS is SUPPOSED to know where m is in memory otherwise the DIM is pointless!

m = picture data (say, a 24 bit per pixel BMP, no header just the data)

PUTIMAGE positions , m

For that matter why do we even have to use MEM in this case?

DIM m as string * length of BMP  picture data

PUTIMAGE positions , m

[SMcNeill]

What are you talking about??

M =_MEMIMAGE(Handle) <-- there's your handle, right there.

With M =_MEMIMAGE(0), 0 is the handle for the current display.

[NOVARSEG]

Hi Steve 
Sorry for the rant I need coffee

I want to Use your method of appending picture data to end of EXE and put that appended data into a memory block.

The last step is to use PUTIMAGE but that requires a handle

COPYIMAGE LOADIMAGE NEWIMAGE are the only instructions that return a handle?

COPYIMAGE I dont get
LOADIMAGE only works with files
NEWIMAGE does not refer to a memory block

So how do I obtain a handle for PUTIMAGE?

[SMcNeill]

With_NEWIMAGE:

Handle =_NEWIMAGE(X, Y, 32)
DIM M AS_MEM: M = _MEMIMAGE(Handle)
'load from file to your memblock -- basically:

temp$ = SPACE$(image_size)
GET #1, data_position, temp$ 'load from drive
_MEMPUT M, M.OFFSET, temp$ 'put to image
_MEMFREE M ‘if not needed anymore.

_PUTIMAGE (whereverX,whereverY), Handle

[NOVARSEG]

Thanks Steve. 

If my BMP is 1024*768 is this correct

Handle =_NEWIMAGE(1024,768, 32)

and is handle a LONG?

I'm looking at the whole thread, bit rusty with the MEM stuff

[SMcNeill]

Yep. 

[NOVARSEG]

Ok im making a BMP picture viewer

DIM a AS _MEM
DIM handle AS LONG
handle = _NEWIMAGE(1024, 768, 32)
a = _MEMIMAGE(handle)

PRINT a.SIZE

prints  1024 * 768 * 4

but I want to use 24 bit per pixel BMPs. Will  I have to parse the 24 bit BMP picture data to include an extra byte for every 3 bytes of data?

The viewer is not going to use _LOADIMAGE