Am Wed, 18 Dec 2013 13:19:09 -0000 schrieb "Regan Heath" <[email protected]>:
> On Tue, 17 Dec 2013 15:13:20 -0000, Marco Leise <[email protected]> wrote: > > > Am Tue, 17 Dec 2013 13:30:25 -0000 > > schrieb "Regan Heath" <[email protected]>: > > > >> On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <[email protected]> > >> wrote: > >> > >> > On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote: > >> >> On 2013-12-16 17:46, Marco Leise wrote: > >> >> > >> >>> Hehe, I guess the whole purpose of the launcher is to run in > >> >>> 32-bit and detect at runtime if the 64-bit main executable can > >> >>> be run or the 32-bit version must be used. > >> >> > >> >> The only advantage of that is that only a 32bit launcher needs to be > >> >> distributed. Perhaps that's the whole idea. > >> > > >> > It is. :) > >> > >> "Process Explorer" by sysinternals, now distributed by M$ does something > >> similar. > >> http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx > >> > >> It is a 32 bit exe, which detects the OS bit width and if it's 64 bit > >> extracts a 64 exe from within itself to run. When you quit that 64 bit > >> exe, it deletes the file it extracted from disk. It's quite a neat > >> solution. > >> > >> R > >> > > > > Only if your executable is self-contained. If you already have > > external DLLs or assets you can as well have a launcher and 2 > > actual binaries. > > I don't see why that changes things? Sure, you cannot extract your > *static* dependent dlls (those linked at compile time with libs), those > have to exist before you can execute your 32 bit launcher. But, if you > really wanted to, you could extract and runtime load dlls no problem. > > R That's my point. If you really wanted, you could do that but you can as well have a launcher and 2 application binaries and avoid this repeated file extraction/deletion and save yourself some troubles at the end of the day. -- Marco
