Member Avatar for babu02021964

Hi,
I wish to embed an existing executable file within my executable and execute it. I am using Visual C++. Is there a way to do this ? Any reference or idea will be greatly appreciated. Thanks

  • 6 Contributors
  • 7 Replies
  • 136 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Salem

Dani AI

Generated

asked about bundling a set of small games inside a single executable. asked why, noted legitimate reasons for keeping files together, and suggested a simple menu plus separate files. The notes below do not duplicate embedding techniques already mentioned in the thread; they focus on operational, security, and maintenance concerns that are often missed when packaging executables together.

Bundled executables frequently trigger antivirus heuristics, especially when the wrapper writes a payload to disk and executes it. Code signing (Authenticode) for the distribution greatly reduces false positives and builds user trust; modifying a signed binary after signing typically breaks its signature. Multi-engine scanning during QA and testing on constrained user accounts and common AV setups will catch most real-world problems before wide release. License obligations for any third-party games must be verified before redistribution.

Execution context and cleanup matter as much as the packaging method. Launching an external game as a child process is handled by the OS, including bitness differences; attempting in-memory or in-process execution is advanced, fragile, and prone to compatibility and security issues. Elevation prompts depend on install location and manifests; extracting payloads into per-user locations avoids unnecessary UAC. Extraction should use uniquely named temporary files, predictable cleanup (delete-on-close or explicit removal), and integrity checks (cryptographic hashes) to guard against corruption or tampering.

For a kids-oriented launcher, prioritizing a simple, maintainable distribution model pays off: sign releases, publish hashes and version metadata, test across AVs and limited accounts, and keep a clear update path for individual games. Tying back to the thread, the rationale raised by is valid; combining that with the operational checklist below reduces support friction and security risk.

  • Sign final binaries and publish checksums
  • Test on limited user accounts and multiple AV engines
  • Use secure, unique temp names and deterministic cleanup
  • Record version metadata and support per-game updates
  • Verify redistribution rights for every bundled game

Recommended Answers

All 7 Replies

Member Avatar for Comatose

Antibiotics anyone..... antibiotics?

commented: Hehe +14
Member Avatar for MosaicFuneral

There's an easy way, yes. Why would you want to?

Member Avatar for ddanbe

Antibiotics only help against bacteria...

Member Avatar for Comatose

Antibiotics only help against bacteria...

Uh Oh.... then I guess we are in a world of hurt.

Member Avatar for babu02021964

There's an easy way, yes. Why would you want to?

I have a bunch of kids small games. I wish to present them through my application.

Member Avatar for Ancient Dragon

There are some legitimate reasons to do such a thing. I've done something similar before so that I could keep the two files together without resorting to writing an installation program.

I think there are at least two choices:

1) compile it as a resource in the resource file.

2) just append it to the end of the executable and extract it yourself whenever you want to. First get the size of the program without the attachment, attach the file, then append another line that is the size of the original program. After than, in the original program add some code that extracts the appended file.

Member Avatar for Salem

So what's wrong with a simple menu program, and a sub-directory containing all the games?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.