Page 1 of 1

64 bit version of APL+Win

PostPosted: October 3rd, 2013, 2:26 pm
by jeff.koloseus
Is consideration being given to developing a 64 bit version of APL+Win?


Re: 64 bit version of APL+Win

PostPosted: October 4th, 2013, 10:02 am
by Tech Support

Thanks for your post.

There have been some discussions on whether to proceed with the development of a 64-bit APL+Win
and the tangible benefits it would deliver to our customers. However no decision has been made
at this time.

To better understand your needs, what limitations are there in the current system that you would like
to overcome and what specifically are you looking for or to do in a 64-bit version of APL+Win that may
or may not possible in the current system?

Re: 64 bit version of APL+Win

PostPosted: October 4th, 2013, 10:20 am
by Davin Church
I am told that recent and future versions of Windows aren't supporting 32-bit environments any more. Will 32-bit APL continue to run properly in these 64-bit-only environments?

Re: 64 bit version of APL+Win

PostPosted: October 4th, 2013, 10:58 am
by Tech Support
Davin Church wrote:I am told that recent and future versions of Windows aren't supporting 32-bit environments any more. Will 32-bit APL continue to run properly in these 64-bit-only environments?

I wasn't aware of this. What references do you know of that supports your assertion?

Re: 64 bit version of APL+Win

PostPosted: October 4th, 2013, 11:17 am
by Davin Church
I'd just been told this by a client because they're worried that we won't be able to run in future 64-bit environments. I think they're talking about the XP emulator window not being available any more. But I don't know if there will be a problem with running well-behaved 32-bit programs natively under a 64-bit OS, which is why I asked - it may still be supporting this mode fine.

If you don't already have an answer off the top of your head, then perhaps it's time to dig into it in more detail and find out what exactly will and won't be supported?

Re: 64 bit version of APL+Win

PostPosted: October 4th, 2013, 11:30 am
by Tech Support
If it's of any comfort to your client, you can inform them that at the present time that all
current 64-bit Windows operating systems (i.e., WinXP thru Win8 workstations and servers)
support APL+Win.

Re: 64 bit version of APL+Win

PostPosted: October 4th, 2013, 2:58 pm
by jeff.koloseus
We have a possible future application where the workspace size could be a gigabyte. This does not leave much "headroom" in the 32 bit environment. A 64 bit version would eliminate most concerns about the feasibility of our approach.

Re: 64 bit version of APL+Win

PostPosted: October 9th, 2013, 1:30 pm
by Tech Support
This shouldn't be a problem for you in the future since APL+Win already supports workspaces over 1 GB in size. The only time this might not be achievable is when third-party Dlls are used with APL+Win and they're loaded in memory in such a way as to prohibit APL+Win from allocating Windows in large contiguous blocks. However, If your applications aren't using third-part DLLs, then this is not a factor.

Re: 64 bit version of APL+Win

PostPosted: October 9th, 2013, 2:20 pm
by jeff.koloseus
In my prior post I mentioned how our workspace size could reach a gigabyte for a potential project. Since this is in the future it's possible that the requirements will exceed my estimate. I've seen this before, where changes in technology enable new and unanticipated situations. I'd feel better if APL2000 was working on a 64 bit version. By the way, Dyalog and MicroAPL both offer 64 bit versions of APL.

Re: 64 bit version of APL+Win

PostPosted: November 8th, 2013, 5:45 am
by Ajay Askoolum
32 bit Windows can allocate 2GB to any individual process and is restricted to handling file sizes up to 2GB I believe. This is probably adequate for most applications.
I have no requirement for 64 bit arithmetic.

The biggest handicap with a 64 bit APL+Win is that it will NOT be able to use the hundreds of 32 bit COM objects readily available on the Windows platform. Windows exposes 32 bit COM objects to 32 bit applications and 64 bit COM objects to 64 bit applications.

Re: 64 bit version of APL+Win

PostPosted: November 13th, 2013, 1:37 am
by joe_blaze
Several issues need to be considered if an APL+Win 32-bit application were ported to an APL+Win 64-bit application including (but not limited to):

    ActiveX: Microsoft x64 applications cannot access 32-bit ActiveX objects 'in-process'. Are 'out-of-process' analogues or X64 analogues of ActiveX objects available?

    Hardware drivers: Are x64 drivers available for all hardware to be included in an application system?

    Assembly language programs: Are 64-bit versions available?

    External dlls: Are x64 versions of traditional dynamic linked libraries accessed via []na or []call available?

    Application architecture: Although an x64 application can access more memory than a 32-bit application (2-4Gb vs. 8TB), in Microsoft Windows the maximum object size remains 2Gb. Thus an APL+Win application that used a large in-memory variable would not 'scale-up' in an x64 application, because that APL variable would still be limited to 2Gb. Will the application system architecture benefit from additional memory?

    Separate versions necessary: While both 32-bit and x64 hardware still exists, an APL+Win application software developer would need to prepare two versions of that application, maintain both and manage distribution of appropriate versions to customers. Are customers of an application system going to be using both x64 and 32-bit hardware?

    Performance: X64 applications have the benefit of additional cpu registers, so that floating-point arithmetic should have improved performance, however x64 pointers are bigger, so that the memory requirement for running an x64 program is somewhat larger than that for a 32-bit program. Will the application system performance actually improve when ported to x64 hardware?

    Numerical Precision: In addition the precision of floating-point arithmetic in the x64 environment may differ from that of the 32-bit environment. Have the results of all application system numerical algorithms been compared in X64 and 32-bit environments?

    User Interface Development: The []wi GUI tools of APL+Win are based on Win32 technology, so these tools may be different or not available in an x64 version. Other technology such as .Net (System.Windows.Forms, WPF, Silverlight) or HTML5/JavaScript may need to be used to create a GUI and interface with APL as a calculation engine. Has a suitable GUI been prepared for the x64 version of the application system? Has the application system architecture been updated to separate the GUI from the business rules and calculations?

The above issues are not sufficient to rule out development of an x64 bit version of APL+Win.
Development of an x64 bit version of APL+Win will depend on significant customer support for such an effort.

APL2000 is committed to providing what customers need by fully supporting the APL2000 products which have been developed thus far and developing new products that improve customers application systems.
In addition the VisualAPL product, available since 2006, has full support for both 32- and 64-bit application types using the same VisualAPL source code and the same resulting executable.

Re: 64 bit version of APL+Win

PostPosted: January 22nd, 2014, 1:20 pm
by Eric.Lescasse

As an APL+Win distributor, I did get a number of requests for a 64-bits version of APL+Win.
I think customers do not realize all the consequences of this and all the things you'd have to do to create a full 64-bits version of APL+Win.

However their requests are there!

For me, the problems are probably similar to what happened when moving from a 16-bits version of APL to a 32-bits version (maybe more complex now though, of course, because APL+Win supports more things), which did happen and did happen very successfully. APL*PLUS PC evolved in APL*PLUS II which was immediately called "Zippy" because it could handle very large arrays so fast.

Yes, there are "millions" of ActiveX out there that can be used with 32-bits APL+Win, but there were "millions" [I exagerate] of 16-bits VBXs that could be used before ActiveX existed. And that did not prevent creating a 32-bits version of APL+Win.

Also, doing a 64-bits version of +Win does not mean giving up with the 32-bits version at all. It would just be an additional version for the people who need it, i.e. who need very large workspaces, for example. A possible approach could maybe be to do a 64-bits version of APL+Win very progressively over time, starting with the raw interpreter first, then later adding 64-bits ASMFNS functions, then later adding support for 64-bits DLLs, etc. And starting soon enough would kind of guarantee that APL+Win will still be there if one day 32-bits software no longer runs on Windows.