On Mon, Jun 9, 2014 at 1:45 PM, Rick McGuire wrote:
>
> On Mon, Jun 9, 2014 at 4:37 PM, Mark Miesfeld wrote:
>
>> On Mon, Jun 9, 2014 at 1:24 PM, Rick McGuire
>> wrote:
>>
>>> Spotted a couple of things about the how the NSIS script is currently
>>> set up:
>>>
>>> 1) We're setting the variabl
On Mon, Jun 9, 2014 at 4:37 PM, Mark Miesfeld wrote:
> On Mon, Jun 9, 2014 at 1:24 PM, Rick McGuire
> wrote:
>
>> Spotted a couple of things about the how the NSIS script is currently set
>> up:
>>
>> 1) We're setting the variable NODOTVER on the makensis command line, but
>> I don't see any re
On Mon, Jun 9, 2014 at 1:24 PM, Rick McGuire wrote:
> Spotted a couple of things about the how the NSIS script is currently set
> up:
>
> 1) We're setting the variable NODOTVER on the makensis command line, but
> I don't see any references to this in the script. Is this still needed?
>
It was
Well, it matters here, because we're passing in x64 or x32 and the code is
looking for x86_64. So either the command line is not passing the correct
value, or the code is testing for the wrong one.
Rick
On Mon, Jun 9, 2014 at 4:31 PM, Michael Lueck
wrote:
> Rick McGuire wrote:
> > "x64", but
Rick McGuire wrote:
> "x64", but the script code is testing for the value "x86_64". One of these
> probably has to change...which one?
I suppose x64 could mean any 64-bit chip, not specifically Intel comparable.
IA64 comes to mind. I would lean towards spelling out "x86_64".
I am thankful,
-
Not sure about #1 but for #2 I would always test for 64 bit, but that is
just my preference. I don't think it really matters a whole lot.
David Ashley
On Mon, 2014-06-09 at 16:24 -0400, Rick McGuire wrote:
> Spotted a couple of things about the how the NSIS script is currently
> set up:
>
>
> 1
On Jun 9, 2014, at 10:50 AM, David Ashley wrote:
> The bottom line is that any library or application that is 32 bit only
> would not be usable in a 64 bit operating system.
^--- Windows
Right now I have 135 processes running of which 24 are 32bit X
Spotted a couple of things about the how the NSIS script is currently set
up:
1) We're setting the variable NODOTVER on the makensis command line, but I
don't see any references to this in the script. Is this still needed?
2) The makensis command line is setting the variable CPU to either "x32"
Jon,
You don't need to be overly concerned with this, in my opinion.
The ooRexx code base builds on both 32-bit and 64-bit Windows and will
continue to build that way as long as your current machines are still
running.
--
Mark Miesfeld
On Mon, Jun 9, 2014 at 12:03 PM, Sahananda (Jon) Wolfers
No, David is definitely not suggesting adding all 32-bit support.
Rick
On Mon, Jun 9, 2014 at 3:03 PM, Sahananda (Jon) Wolfers <
sahana...@windhorse.biz> wrote:
> Just speaking for myself here:
>
> I have upwards of 70 machines I am responsible for running ooRexx on 32Bit
> processors (Celeron
> Maybe this is also a good point to address Windows. At this
> point Microsoft has not announced anything about dropping
> support for 32 bit libraries/apps. So I think that we can
> safely assume Microsoft will continue to support 32 bit apps
> and libraries since the number of 32 bit only
Just speaking for myself here:
I have upwards of 70 machines I am responsible for running ooRexx on 32Bit
processors (Celeron 430, Pentium 4, Northwood, Celeron M320, Barias,
Coppermine etc..).
They are all running Windows OSs (Mainly the now defunct XP).
Nearly half of them are tills, so expensiv
The bottom line is that any library or application that is 32 bit only
would not be usable in a 64 bit operating system. Perhaps the most
obvious library is the IBM DB2 Rexx libraries. These are 32 bit only (no
64 bit libraries exist) and would not work on a 64 bit OS, no matter
what version of ooR
David Ashley wrote:
> It looks like the new Red Hat EL 7.0 will only be available in x86_64
> format (no i384/486/586/686 version).
I seem to recall reading something about an end of x86 coming to Ubuntu as well.
What ever point the distro vendors stop x86 support, obviously ooRexx will not
be
Well, if you are still on a 32-bit machine, you won't be able to upgrade to
those 64-bit versions, although I think you'll find that every Intel or AMD
machine produced in the last 10 years can actually handle a 64-bit install.
If is only when you install a 64-bit OS and are also forced to instal
Hi David
Could you just lay out for us what that would mean in terms of users still
on 32bit machines and also those reliant on extensions like rexx\sql,
rexxCurl etc.
thanks,
Jon
On 9 June 2014 17:20, David Ashley wrote:
> The short answer is no. The longer answer is that if you also load
The short answer is no. The longer answer is that if you also load the
32 bit base libraries then the answer is yes. But the question is
whether or not those libraries will be available. I think the answer is
probably no on that one, but I could be wrong. The basic ide here is to
move to 64 bit and
Does the 64-bit format still support running 32-bit executables?
Rick
On Mon, Jun 9, 2014 at 11:45 AM, David Ashley
wrote:
> This is just something I am throwing out there with some information
> added so everyone can think about it.
>
> It looks like the new Red Hat EL 7.0 will only be availa
This is just something I am throwing out there with some information
added so everyone can think about it.
It looks like the new Red Hat EL 7.0 will only be available in x86_64
format (no i384/486/586/686 version). And I am hearing that Fedora may
follow that strategy with the Fedora21 release com
I did this in then nsis template file...it was a pretty easy change.
Rick
On Monday, June 9, 2014, Mark Miesfeld wrote:
> On Mon, Jun 9, 2014 at 7:29 AM, Rick McGuire > wrote:
>
>>
>> btw, do we still need the isNT tests in the .nsi file? We can eliminate
>> one include file if those are no l
On Mon, Jun 9, 2014 at 7:29 AM, Rick McGuire wrote:
>
> btw, do we still need the isNT tests in the .nsi file? We can eliminate
> one include file if those are no longer needed.
>
We don't really need it. But, if we remove it, the section for setting the
path needs to be fixed up, if I recall
Yeah, configure_file() is a useful command. I'm actually making good
progress with this (in stages). My current plan is to generate include
files for both the component file manifests and the shortcuts (the
shortcuts are done). This will all get created in build directory, the
.nsi file well get
Rick,
Okay.
The configure_file() command looks promising. That's what I was trying to
do yesterday by using a NSIS.template.in file that was a copy of our old
oorexx.nsi file and just have variables for the /D options. But, it didn't
work at all.
--
Mark Miesfeld
On Mon, Jun 9, 2014 at 2:50
Mark,
One of the difficulties with converting our file to an NSIS template was
getting around which variables in the template are done by directly
substituting variables from the CMake file and which ones are done via the
generator. In particular, the generator was causing me the biggest issues.
24 matches
Mail list logo