Hi!
There's a bug #50444 (https://bugs.php.net/bug.php?id=50444) regarding
PDO-ODBC types with 64-bit builds. Looks like we are using wrong types
in a couple of places. I've merged the patch for 5.6, but I'm not sure
what to do with 5.5 and maybe 5.4. The thing is technically it's
structure change which may break BC. OTOH, the old way didn't seem to
work on 64-bit anyway. So, I wonder what is the status of our 64-bit
support - e.g., I see we don't even have official windows build for
64-bit and 5.4, so it may not make sense to put it in 5.4, but what
about 5.5?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi Stas,
Hi!
There's a bug #50444 (https://bugs.php.net/bug.php?id=50444) regarding
PDO-ODBC types with 64-bit builds. Looks like we are using wrong types
in a couple of places. I've merged the patch for 5.6, but I'm not sure
what to do with 5.5 and maybe 5.4. The thing is technically it's
structure change which may break BC. OTOH, the old way didn't seem to
work on 64-bit anyway. So, I wonder what is the status of our 64-bit
support - e.g., I see we don't even have official windows build for
64-bit and 5.4, so it may not make sense to put it in 5.4, but what
about 5.5?
I would bother for either 5.4 or 5.5 64bit support for windows. Or
maybe even for 5.5 in general.
We have partial somehow hackish 64bit implementation. It does work for
most cases on systems with 64bit long with a couple of issues. But for
windows, even the 64 bit builds we provide are experimental and by no
mean match the features available on 64bit unices.
php 6 will actually have real 64bit support, hopefully, the int64
branch has all necessary changes and I seriously hope that the RFC
will be accepted.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
php 6 will actually have real 64bit support, hopefully, the int64
branch has all necessary changes and I seriously hope that the RFC
will be accepted.
Pierre ... I'm still fighting 32/64 bit problems with windows on legacy systems.
64 bit windows does not allow access to the parallel port which we use for
controlling additional hardware. While not directly a problem for simple code,
is the way 64 bit builds of windows handle memory access a problem for PHP
builds? Having moved the servers over to Linux for PHP and database support, the
remaining elements are STILL locked to 32bit windows simply because of legacy
hardware, but I'm trying to work out the best way forward as we are still tied
to XP on a number of systems ... with PHP access for control ... so things are
getting very messy :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
hi,
Pierre Joye wrote:
php 6 will actually have real 64bit support, hopefully, the int64
branch has all necessary changes and I seriously hope that the RFC
will be accepted.Pierre ... I'm still fighting 32/64 bit problems with windows on legacy
systems. 64 bit windows does not allow access to the parallel port which we
use for controlling additional hardware.
I have no parallel port at hand to do tests but it should work like
any devices. Please report a bug, add a stack trace (process monitor
output) to see what happens.
While not directly a problem for
simple code, is the way 64 bit builds of windows handle memory access a
problem for PHP builds? Having moved the servers over to Linux for PHP and
database support, the remaining elements are STILL locked to 32bit windows
simply because of legacy hardware, but I'm trying to work out the best way
forward as we are still tied to XP on a number of systems ... with PHP
access for control ... so things are getting very messy :(
If you use XP it means you use 5.4, we do not provide any 64bit
support for windows with 5.4, only 5.5+, experimental.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
hi,
Pierre Joye wrote:
php 6 will actually have real 64bit support, hopefully, the int64
branch has all necessary changes and I seriously hope that the RFC
will be accepted.Pierre ... I'm still fighting 32/64 bit problems with windows on legacy
systems. 64 bit windows does not allow access to the parallel port which we
use for controlling additional hardware.I have no parallel port at hand to do tests but it should work like
any devices. Please report a bug, add a stack trace (process monitor
output) to see what happens.
This is not a general PHP problem, but relates to use of the parallel port in
other hardware drivers. NTPort lib still only supports 32bit applications, and
'fastmode' access is specifically blocked by 64 bit windows! A number of drivers
that my legacy hardware systems use are unusable on 64 bit windows and those
projects are now advising staying with 32bit windows as they have been
unsuccessful in producing a 64bit driver due to the blocks applied in kernel access.
While not directly a problem for
simple code, is the way 64 bit builds of windows handle memory access a
problem for PHP builds? Having moved the servers over to Linux for PHP and
database support, the remaining elements are STILL locked to 32bit windows
simply because of legacy hardware, but I'm trying to work out the best way
forward as we are still tied to XP on a number of systems ... with PHP
access for control ... so things are getting very messy :(If you use XP it means you use 5.4, we do not provide any 64bit
support for windows with 5.4, only 5.5+, experimental.
My point is that moving things to 64 bit builds of windows, which are the norm
for windows 8.1 - or at least I have not yet found a pre-installed 32 bit
windows 8.1 - is now highlighting problems that are not easy to get around.
Simply running 32bit builds of applications does not mean they will actually
work on 64it windows! One needs to have 32 bit windows for some kit for which
there is no later drivers. XP may be end of life, but there is currently no
alternative that I've managed to get working on even W7 and now testing on W8.1
is throwing up new failures. Having now picked up a 32bit build of W8.1 I'm
hoping to make some progress, but this is all very messy and time consuming!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
How about using a separate machine with linux/php to access your legacy
hardware? You could then create a php web service and expose methods to
read/write to the hardware. This will allow you to run php on window 64-bit
and communicate with your linux box via web services.
Best regards,
__
Raymond
Pierre Joye wrote:
hi,
On Mon, Apr 21, 2014 at 12:26 PM, Lester Caine lester@lsces.co.uk
wrote:Pierre Joye wrote:
php 6 will actually have real 64bit support, hopefully, the int64
branch has all necessary changes and I seriously hope that the RFC
will be accepted.Pierre ... I'm still fighting 32/64 bit problems with windows on legacy
systems. 64 bit windows does not allow access to the parallel port which
we
use for controlling additional hardware.I have no parallel port at hand to do tests but it should work like
any devices. Please report a bug, add a stack trace (process monitor
output) to see what happens.This is not a general PHP problem, but relates to use of the parallel port
in other hardware drivers. NTPort lib still only supports 32bit
applications, and 'fastmode' access is specifically blocked by 64 bit
windows! A number of drivers that my legacy hardware systems use are
unusable on 64 bit windows and those projects are now advising staying with
32bit windows as they have been unsuccessful in producing a 64bit driver
due to the blocks applied in kernel access.While not directly a problem for
simple code, is the way 64 bit builds of windows handle memory access a
problem for PHP builds? Having moved the servers over to Linux for PHP
and
database support, the remaining elements are STILL locked to 32bit
windows
simply because of legacy hardware, but I'm trying to work out the best
way
forward as we are still tied to XP on a number of systems ... with PHP
access for control ... so things are getting very messy :(If you use XP it means you use 5.4, we do not provide any 64bit
support for windows with 5.4, only 5.5+, experimental.My point is that moving things to 64 bit builds of windows, which are the
norm for windows 8.1 - or at least I have not yet found a pre-installed 32
bit windows 8.1 - is now highlighting problems that are not easy to get
around. Simply running 32bit builds of applications does not mean they will
actually work on 64it windows! One needs to have 32 bit windows for some
kit for which there is no later drivers. XP may be end of life, but there
is currently no alternative that I've managed to get working on even W7 and
now testing on W8.1 is throwing up new failures. Having now picked up a
32bit build of W8.1 I'm hoping to make some progress, but this is all very
messy and time consuming!--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Stas,
Hi!
There's a bug #50444 (https://bugs.php.net/bug.php?id=50444) regarding
PDO-ODBC types with 64-bit builds. Looks like we are using wrong types
in a couple of places. I've merged the patch for 5.6, but I'm not sure what
to do with 5.5 and maybe 5.4. The thing is technically it's structure
change which may break BC. OTOH, the old way didn't seem to work on 64-bit
anyway. So, I wonder what is the status of our 64-bit support - e.g., I
see we don't even have official windows build for 64-bit and 5.4, so it
may not make sense to put it in 5.4, but what about 5.5? --
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I've just tested this patch - the compiler is fine with it, though I have
5 failing tests. Despite that I'd say it's fine to merge this patch in as
I see some places where the corresponding vars are passed by reference to
the SQL API. That is the 64 bit ussue which can lead to a crash without
this patch.
So for 5.4 it could only make sense if one does homemade 64 bit builds,
5.5 would make sense to be merged back though it's experimental, and into
str_size_and_int64 it'll slide automatically anyway. Otherwise it is just
harmless on 32 bit.
Shortly I'm going to investigate on the failing tests I've mentioned.
Regards
Anatol