Is this a 32 or 64bit windows?

Im debating whether its worth offering a 64 bit WIndows build.
To help me decide, I want to start adding a ‘message to me’ when people register so that I know if their Windows is 32 or 64 bit
Is there a simple way to tell them apart?
MBS plugin solution is fine.

Is64bitWindows in SystemInformationMBS module does this.

Reports true for 32-bit app in 64-bit Windows.

Thanks Christian.

I really wish all my Google searches for MBS stuff didn’t return Filemaker examples…
:>

Use +Xojo with the search or limit to domain monkeybreadsoftware.net for our Xojo documentation.

2 Likes

https://www.pcbenchmarks.net/os-marketshare.html

This graph shows all current versions of windows in use (xp, 7, 8, 10), 32-bit is almost gone this days.

In real life, 32 bits is a little more used, but still, if your app dont requiere more than 2Gb of RAM or other 64 bits only feature, there is no significant reason to have a 64 bits one

2 Likes

64 bit is the way to go when you feel Xojo is stable for that. 32 bit is the current Xojo safe road. I’ve tried it when Joe was around, but it had flaws, and later so many problems in 2017, 2018 and 2019 versions that I gave up and offered only 32 bit options. Not sure how 2020 is now. But the high level computing future is 64bit only, all computing devices processors, even mobile processors are migrating to 64bit only. Only IOT and low level devices will stick in 32bit… for a while.

Ive a licence up to 2019, but have been building stable 32bit with Xojo 2015

I’ve been trialling some 64bit builds in 2018
(Damned if I want to use new framework or API2)
Even in 32 bit it’s iffy with some things, but I’m working through them.

Looking at what gets built, I’ve just found a big folder of locales (14Mb) which seems to serve no useful purpose.
Looking at the contents, I’m guessing this is all to do with pointless language definitions for HTMLViewer.

And for some reason, code that works through a memoryblock byte by byte is incredibly slow in debug on 2018, compared to 2015

But I may start to offer a choice soon after I have tested, and assured myself that the release build works fast enough

I have to say that I saw many fixes after 2018, some in 2020 (well… some are just enhancements avoiding a worse behavior). If I would try 64bit again, I would try with the latest version.

I have to say that I saw many fixes after 2018,

Well, after a few days of testing, I have to say that I hope so.

I got the 64bit build to run using 2018.
The footprint takes up more than 6 times as much disc space.
When running, the 64 bit version (of the same source code)

  • runs slowly,
  • doesnt refresh the screen reliably
  • displays text in different sizes (so the screen layouts don’t quite work)
    and
  • hogs between 1.5 and 2.5Gb of memory, where the 32 bit version uses 1/10 of that.

I’ll stick with 32bit for a while… :wink:

2 Likes

Jeff, I ran into a lot of problems like this. What I have found is the 32-bit version of my apps run very fast on both 32-bit and 64-bit systems, as well as on Windows 7 and Windows 10. The 64-bit version of my apps suffered from the same screen issues on older Windows 7 systems. But after I took the source code over to a Windows 10, 64-bit system and worked with it a bit (the usual Xojo Windows pseudo-solutions of keeping layered controls to a minimum, and putting in refreshes and invalidates in strategic places) the performance is acceptable. Probably runs at about 80% of the speed of the 32-bit version on Windows 7, just eyeballing it and what it feels like.

I will say this, I was not happy with Xojo on Windows from about 2016r1.1 all the way to about 2019r2 or somewhere around there (so much so that I stopped renewing for a while). Just couldn’t produce anything I was willing to serve up to customers. But that seems to be changing for the better and I feel like I can produce code I am mostly satisfied with that will run on Windows 10, 64-bit in HiDPI well. My Xojo licenses are back to being current, because I think they have addressed most of the issues.

I will still likely produce a 32-bit version for a while, I use 2015r4.1 for that.

Thanks. That’s encouraging.

Probably runs at about 80% of the speed of the 32-bit version on Windows 7, just eyeballing it and what it feels like.

That’s not. There are several points to making a 64bit build, and improved speed would have been right up there.
If it’s not faster, there is no point me wasting time on ‘trying things to make it work’

keeping layered controls to a minimum

Did that years ago.
I have none.

Further to the original question here, I added the test for 64bit-ness into my registration code.
It’s early days, but so far 20% of my customers are using a 32bit Windows installation.

All the database and normal code runs as fast or maybe a bit faster. It is the visual look and feel that is still a little slower. But the 32-bit apps are very fast and 80% of that is not something that will bother most users (the Mac 64-bit version just scream with speed, definitely faster than the 32-bit version on the Mac I produce). But the looks of the app running in Windows HiDPI and think more than make up for the 20% loss in speed. So for the time being, I’ll just produce both and my uses can run which version they want.

If you are building 32-bit with 2015 then you are using the older Windows graphics system. In 2018r1, Xojo switched to using more the more modern Windows graphics system. This doesn’t really have anything to do with 32-bit vs. 64-bit.

https://documentation.xojo.com/topics/user_interface/windows_ui_guidelines.html

Also, newer versions of Xojo support HiDPI which means a lot more graphics data is being utilized if you have it enabled.

https://documentation.xojo.com/topics/graphics/hidpi_support.html

This video from XDC 2018 also has some advice on how to best take advantage of these new features:
https://youtu.be/PMeLdcLV_t0

2 Likes

If you are building 32-bit with 2015 then you are using the older Windows graphics system. In 2018r1, Xojo switched to using more the more modern Windows graphics system.

Which appears to be a great deal slower and unreliable.
I’m not running in HiDpi

best take advantage of these new features

I’ll give it a watch and keep an open mind.

(But a feature that needs an explanation about why it makes things slower doesn’t sound like a feature ,so much as a regression.
Let’s see.)

2 Likes

I think that is likely the issue as Paul says. I recall all kinds of problems through 2016, 2018 and into 2018 ( conversed/tested with William Yu a bit back in 2016/2016 when this issue was a big problem). At some point in 2018, it got better on HiPDi systems.

I just did a highly unofficial set of tests, but it generally shows what I see and feel. Scrolling through a ListBox that makes up one of my screens with hundreds of preloaded rows from a database (counting how many can be scrolled in 10 seconds). In general, the 64-bit versions of the apps are about 10% faster than the 32-bit counterpart on the same system (a new, fairly high-end Dell):

Low-Res build, 32-bit, Xojo 2020r2: 110 rows in 10 seconds.
Low-Res build, 64-bit, Xojo 2020r2: 122 rows in 10 seconds.
HiDPI build, 32-bit, Xojo 2020r2: 161 rows in 10 seconds.
HiDPI build, 64-bit, Xojo 2020r2: 172 rows in 10 seconds.

Low-Res build, 32-bit, Xojo 2015r4.1: 358 Rows in 10 seconds.

All of them running on a Windows 10 new system. The builds out of Xojo 2020r2 feel snappier when built with HiDPI enabled, but still feel sluggish when compared to the Low-Res builds out of 2015r4.1. I see similar results when the apps are moved to an older Windows 7 system and ran.

While I would love to crank out one 64-bit build and have it service all users, those that are used to the speed of the normal 32-bit, low-res apps built with 2015r4.1 would be a bit disappointed.

For now I have to maintain two builds. If the user isn’t on a HiDPI montior, they will want the speed. I suspect Jeff is seeing similar things that make him just as wary.

The newer graphics system was a requirement for HiDPI. It also reduced flicker. Think of it similar to the Carbon to Cocoa UI switch on macOS. Carbon graphics were always considered faster than Cocoa graphics, but that was because the older libraries did far fewer things. We have optimized things a bit so that the Windows graphics are faster than they were in those first few releases.

I hope this background helps you choose the best path for you continue to build what works best for you and your customers.

2 Likes

Interesting… As of today, my 32bit customers are double the 64 bits number.
Stop the count!
(too soon?)

Small sample set at the moment, to be fair.

1 Like