On 12/18/2013 05:50 AM, Hugo Florentino wrote:

> BTW, how could I benchmark the performance of both solutions (lets say
> for a few thousand runs) to see if one is more efficient than the other?

There is std.datetime.benchmark:

  http://dlang.org/phobos/std_datetime.html#.benchmark

Ali

On Thu, 19 Dec 2013 10:53:12 -0800, Ali Çehreli wrote:
> On 12/18/2013 05:50 AM, Hugo Florentino wrote:
>
>> BTW, how could I benchmark the performance of both solutions (lets say
>> for a few thousand runs) to see if one is more efficient than the other?
>
> There is std.datetime.benchmark:
>
>   http://dlang.org/phobos/std_datetime.html#.benchmark
>
> Ali

Thanks. I don't know why I missed that.

On Wed, 18 Dec 2013 13:43:44 -0000, Hugo Florentino <hugo@acdam.cu> wrote:

> On Wed, 18 Dec 2013 13:20:45 -0000, Regan Heath wrote:
>> On Wed, 18 Dec 2013 04:22:23 -0000, Hugo Florentino <hugo@acdam.cu> wrote:
>>
>>> On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote:
>>>>
>>>> Make sure you handle if users have a 32bit OS installed on a
>>>> 64bit PC.
>>>
>>> As a matter of fact that was the actual configuration in the system I  wrote the app.
>>> I am now with a friend with the same configuration, and it also seems to  be working.
>>> At work I use Windows 7 x86_64 and it also works.
>>
>> It works because the SYSTEM_INFO member "wProcessorArchitecture" is
>> defined to be "The processor architecture of the installed operating
>> system" .. note, *installed operating system*, not processor
>> architecture.
>>
>
> Well, isn't that what I needed to begin with?

Yes, I was just explaining 'why' it works :)

> That's why I said OS architecture instead of CPU architecture.
> Unless you are refering to something else.

I was just explaining for posterity/future readers.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 19 Dec 2013 09:41:26 -0000, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am Wed, 18 Dec 2013 13:19:09 -0000
> schrieb "Regan Heath" <regan@netmail.co.nz>:
>
>> On Tue, 17 Dec 2013 15:13:20 -0000, Marco Leise <Marco.Leise@gmx.de> wrote:
>>
>> > Am Tue, 17 Dec 2013 13:30:25 -0000
>> > schrieb "Regan Heath" <regan@netmail.co.nz>:
>> >
>> >> On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <hugo@acdam.cu>
>> >> 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.

Sure, but having a self contained exe is useful and *cool* :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/