Run a web server of your choice which hosts the files and serves them via HTTP.

Implement a library like LibCurl into your game to go to the server and ask for the latest files and download them.


Done :-)

Replacing the currently executing binary is not possible on Windows, and is various flavors of hard on various other OS-es (from "almost trivial" to "can't be done.")
Thus, almost all patchers use a ripple launcher. This is the thing that pops up first, maybe asks for your name/password, checks for updates, and if all is OK, actually pushes you into the game.
Typically, that ripple launcher will do something like:

- Get the latest version, and proper hash for that, from server.
- If the installed version is correct, jump to "chain launch."
- Check the download temp directory for a download archive. If it's there, verify the signature. If it matches, jump to "apply patch."
- Clear out the download temp directory.
- Download the new patch archive.
- Verify the checksum of the downloaded patch archive compared to what you expect.
apply patch:
- Unpack the downloaded archive into the game install directory.
- Remove the downloaded archive.
chain launch:
- Start the actual game binary, and exit the patcher. Ideally, you use a semaphore or some other kind of barrier to guarantee that the patcher is dead before proceeding past the loading screen in the game.
actual game:
- The actual game compares a copy of the "chain launcher" binary in its own data files to the copy that's actually installed. If they differ, replace the one that started the game. This allows you to apply a patch to the downloader/patcher application, indirectly.

There are many file- and network- and permission-related things that could go wrong here. However, if you're comfortable developing desktop applications in general, there is nothing particularly new and exciting here, you just need to follow good implementation practices (keep the user informed, provide safe fallbacks for cancelling, error handling, etc.)