Is there someway to include pictures in the exefile?

[KodeZwerg]

but the exe file will be big , maybe better you put it in DLL and link it to the exe

https://github.com/alas82/resource-in-dll.git

And what does that really achieve? You still have to provide the library and in total the size will be bigger than if you'd put the image into the executable, because of the additional overhead of the library file itself minus the resources.

You will benefit of not need to link files in again and again and again for each compile you do.
Index inside dll is fixed and not change, so you practical have a cool resource file where you just need to know once how the indexes are.

[KodeZwerg]

And what does that really achieve? You still have to provide the library and in total the size will be bigger than if you'd put the image into the executable, because of the additional overhead of the library file itself minus the resources.

what you do then if you have software of 100 picture for ex??

It does not matter how many you include since you will not load them all at once, dont you?

[PascalDragon]

And what does that really achieve? You still have to provide the library and in total the size will be bigger than if you'd put the image into the executable, because of the additional overhead of the library file itself minus the resources.

what you do then if you have software of 100 picture for ex??

Still don't care, because in the end it will all completely be on the disk (while not running) as well as the RAM (when running). So why make things more complex when there is no real benefit? (And I don't consider reduced link time a benefit when that means I need to deal with libraries when otherwise I wouldn't need to @KodeZwerg)

[KodeZwerg]

And what does that really achieve? You still have to provide the library and in total the size will be bigger than if you'd put the image into the executable, because of the additional overhead of the library file itself minus the resources.

what you do then if you have software of 100 picture for ex??

Still don't care, because in the end it will all completely be on the disk (while not running) as well as the RAM (when running). So why make things more complex when there is no real benefit? (And I don't consider reduced link time a benefit when that means I need to deal with libraries when otherwise I wouldn't need to @KodeZwerg)

My reason would be more that i do not need to update a .dll file. Anyway, all do like they want to do as long the result does what it should do 

[KodeZwerg]

I mean that exporting resources into a library, exemplary for a game, video, sound, images etc.... the library is like 1gigabyte while the executable is like 5megabyte.
When all is included into main executable (of course that is possible) that updates are very large instead of small patches when working with libraries.

[Arioch]

Still don't care, because in the end it will all completely be on the disk (while not running) as well as the RAM (when running).

....assuming a single application instance.

But if there are several instances (like multi-user computer, therminal sever; or like multi-process server as opposed to multi-thread (remember Apache 1.x; Linux for long did not had adequate threading so just was forking instead)) then you'd better have that birmap in the RAM once (shared by all the users and instances) rather than N times.

[alaa123456789]

Still don't care, because in the end it will all completely be on the disk (while not running) as well as the RAM (when running). So why make things more complex when there is no real benefit? (And I don't consider reduced link time a benefit when that means I need to deal with libraries when otherwise I wouldn't need to @KodeZwerg)

do you mean even the exe size 1 gb , when you run it , it doesn't load into memory?

thanks

[Arioch]

do you mean even the exe size 1 gb , when you run it , it doesn't load into memory?

No, in more or less elaborated operating systems it is mapped to memory, but not necessarily loaded.

And even if it is loaded for a while - its parts then can be removed from memory to free RAM for more data and for other programs running.

-  https://en.wikipedia.org/wiki/Memory-mapped_file
-  https://en.wikipedia.org/wiki/Memory_paging

OTOH some naive antivirus MIGHT be loading entire file before it would let it to be run, especially on a remote (shared by network) drive.
There were cases when Microsoft Office documents were opening from a shared folder dozen times slower than they would open locally because of AV.
And in my personal tests an application suite (copy-protected EXE+BPL+DLL) was run from a network drive (Fast ethernet, approx 10 MB per secong) 3.6 times slower with default antivirus configuraion, than it would have be after careful configuration of AV,

[PascalDragon]

But if there are several instances (like multi-user computer, therminal sever; or like multi-process server as opposed to multi-thread (remember Apache 1.x; Linux for long did not had adequate threading so just was forking instead)) then you'd better have that birmap in the RAM once (shared by all the users and instances) rather than N times.

But that will only work if Windows decides to place the library at the same location for each process and not different ones due to ASLR.

[Arioch]

But if there are several instances (like multi-user computer, therminal sever; or like multi-process server as opposed to multi-thread (remember Apache 1.x; Linux for long did not had adequate threading so just was forking instead)) then you'd better have that birmap in the RAM once (shared by all the users and instances) rather than N times.

But that will only work if Windows decides to place the library at the same location for each process and not different ones due to ASLR.

I did not mean only Windows, but i think TS admin can setup it to different ASLR policies.

For my gut fealing ASLR is about different servers having different addresses, not one same server having different ones.
Also pro-active DLL relocation was a well known speed-up for loading, granted ASLR kills it. Granted, CPU vs HDD speed gap meant direct non-relocated loading was becoming less and less an issue. But with BVMe SSDs, Intel Optane and what not - it would be again :-)