You are here

Apps That Drop Windows XP Support: List, App Homepage Indications

35 posts / 0 new
Last post
John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Apps That Drop Windows XP Support: List, App Homepage Indications

We're now starting to see more apps which are dropping support for Windows XP. I'm wondering how the community would like to handle this. We'd like to maintain a list of last-working versions for users to be able to obtain. We'll include a caveat about bugs, security issues, and it being unsupported, of course.

I'm inclined to have a single page listing all the last-working versions and including links from each app's homepage affected to that page. That way we can have all of them in one place and only have one big notice about why it's a bad idea as well as how to install it so the updater won't offer to update it. It's possible we could also do a specific XP version with a renamed AppID (FileZillaPortableLegacyForXP) as a last release as well using the updated installer so that it will continue to work. We could even include a warning about it being unsupported on install.

Thoughts?

Apps That Have Dropped XP, Last Version Supported

The following apps have dropped support for Windows XP. The last supported version is linked below. Note that these versions are unsupported and may have security issues. They may also be using an older installer with issues installing to UNC paths or 3TB+ drives.

When installing, it's best to install to a renamed directory so that the PortableApps.com Platform's updater won't offer to update it for you later. Something like FileZillaPortableLegacyForXP.

FileZilla Portable 3.9.0.1 (6MB download / 14-22MB installed)
MD5: 47faddd174e6e6dd0fd1a9f684c31e88

grepWin Portable 1.6.3 (975KB download / 2.28MB installed)
MD5: 1f820912d08b46778a96193392d821a9

Marble Portable 1.9.0 (24MB download / 38MB installed)
MD5: 7db1bcdce1c5f1fafcb3858538314675

Sigil Portable 0.7.4 (25MB download / 93MB installed)
MD5: 4840d50b1ba53070cc96e32a3b6ef5d5

Wm ...
Offline
Last seen: 7 years 2 months ago
Joined: 2010-07-17 12:37
List seems best to me for now.

As an XP user by choice I'm OK with an informative list.

e.g. I can find another FTP client easily or use the command line and there are other PA's that can do FTP anyway.

What the community might want to keep tabs on is not so much "has app ABC dropped XP" so much as "does PA no longer have an FTP client that runs under XP". i.e. think of it in terms of availability of function rather than availability of App.

Wm

Freehunter
Offline
Last seen: 1 week 3 days ago
Joined: 2014-06-26 10:21
XP and SSE2

Your idea sounds good. Appreciate the notices that have started to show up on some the app's homepages.

As I mentioned in LibreOffice, the problem seems not to be so much a problem of XP but the CPU it is running on. If the CPU supports SSE2 then XP with SP3 should be good for awhile longer. Unfortunately the developers releasing new versions of software are not considering backward compatability for older CPUs and OSs.

A quick google turned up SSE2 issues with Skype 6.2, uTorrent 3.4, and MuseScore 2 beta. There was a post at MuseScore that was pretty in depth:

http://musescore.org/en/node/31361

The beta wouldn't bother PAc yet, I don't know if there have been any issues with Skype or uTorrent.

I think that this will probably hit some other Apps like Blender, Gimp, K-3D, and VLC sooner rather than later if it has not already.

I think an addition to your proposed page instructing the users to try CPU-Z to check their CPU. If it doesn't support SSE2 then they are probably stuck with an older version of the App they are trying.

Maybe a sticky somewhere is needed to alert XP users to check their CPU if they are having problems with new version of an App.

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Could Add To PAF

I'm planning on adding a MinOS setting to appinfo.ini anyway for the platform to use. That way all apps, PAL or not, can advertise it to the platform and the platform can let the user know by greying the apps out. We could add an SSE2 entry as well and I can easily have the platform detect whether the current PC supports it. We wouldn't go testing apps for it individually, but our users who notice it can let us know and we can update the apps as new versions come out (see LibreOffice, Google Chrome, etc). That way it wouldn't increase testing but it would let us make things easier on users with much older hardware. Thoughts?

Sometimes, the impossible can become possible, if you're awesome!

Freehunter
Offline
Last seen: 1 week 3 days ago
Joined: 2014-06-26 10:21
Sounds good

Sounds good if you are already planning on adding a MinOS check. If adding a check for SSE2 doesn't require a lot of extra overhead that sounds good too.

When you say grey out the App, do you mean making it unavailable or just as a warning that there could be problems?

If making it unavailable, would there an order of precedence? What happens if MinOS=Win7 but PC with XP and SSE2 would run App. Or would you set MinOS=WinXP but also require SSE2 be supported in that case otherwise doesn't run?

I know some developers are writing their programs so will not run under XP even though it would work with SSE2 support.

It is amazing all the things you have to consider and allow for in building the platform. Thanks again for all your work.

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Separate

The two entries will be separate and only be set when we know a given app won't run without the indicated entry. So RequiresSSE2 will only be set to true when the app won't run without it. MinOS=Vista would only be set for an app that requires Vista and up. They're separate things in the compiler as well. Many of the apps that are Vista and up require specific entries in the Windows kernel that they make use of, so when you try to run them on XP, they'll fail with a kernel error of some sort. Apps that require SSE2 are simply compiled to take advantage of the CPU instructions available on SSE2 processors for better performance.

Sometimes, the impossible can become possible, if you're awesome!

Wm ...
Offline
Last seen: 7 years 2 months ago
Joined: 2010-07-17 12:37
2nd seperate

one is hard the other soft. if SSE2 is the hard bottom limit and XP the soft one it may make sense to set things up to ck generally not specifically because XP apps may be diminishing but because you'd end up doing it at some point anyway as the next major OS or (at the time) HW innovation drops out of the frame.

Make sense? i.e. don't set the framework up for XP and SSE2 but for OS and HW lower rungs in general.

Wm

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
What's the difference between 'hard' and 'soft' minimums?

I don't see what you mean about SSE2 being a "hard bottom limit" and XP being a "soft one".
I guess I can understand the 'hard limit', software that's been compiled to take advantage of SSE2 simply won't run on a CPU that doesn't support SSE2, whether you're running Wine, Windows 2000, XP, Vista, Windows 7, or ReactOS. But similarly software that's been built with a compiler that doesn't support making XP compatible binaries will fail just as completely due to the lack of certain kernel functions which it expects. So why is MinOS=XP any 'softer' than the ReqSSE2=True?

~3D1T0R

Wm ...
Offline
Last seen: 7 years 2 months ago
Joined: 2010-07-17 12:37
Possible edge case LO as example

It seems there is a version of LO that will work on XP on a processor with SSE2 but not on XP with a processor without SSE2.

My reading of the thread was that it wasn't a binary

XP compliment LO

i.e. (and I think John has got this right) there are two factors, one hard one soft

Wm

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Both Hard

If by soft fail and hard fail, they're both hard fails in our usage. If we mark an app as MinOS=Vista, that means it requires Vista and later no matter what CPU or anything else you have. It won't work on XP full stop. The same goes for requiring SSE2. An app that requires SSE2 won't work without it due to the way it was compiled.

Note that we make a best effort to get apps working on XP even when no longer supported. For example, Blender is now only supported on Windows Vista and later, but we add the appropriate Visual C++ runtimes to our package and it continues to work on Windows XP. It's like a later release will be compiled with a newer compiler and not work on XP at all, but that's a different scenario.

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Possible Option

One other possible option would be to prompt users when they attempt to run a Vista and up app on an XP machine to allow them to automatically download and install the XP-only one with the appropriate warnings. This can be done automatically by the updater and we could copy their settings from one to the other. This might be overkill, though.

Sometimes, the impossible can become possible, if you're awesome!

Wm ...
Offline
Last seen: 7 years 2 months ago
Joined: 2010-07-17 12:37
related to that

related to that I might have apps on my USB that needn't run on the system I'm using right now but might work on another system I have access to and vice versa.

I'd probably go for the lowest common denominator version on my USB of "LargeAppX" so if I was updating on something shiny and new I wouldn't want it updated to the one that worked on the system I was updating on.

Ponder. Since there are only a few folks discussing this at the moment I'm going to suggest overkill and see what others say.

My why is that I'm wondering if the number of choices isn't going beyond the reminder that XP is running out (yes, users should know) and into multiple choice

+++
I have limited space on this USB, I'm updating on a Win8 system, should I update my XP compatible AppXYZ only to find when I get to location G which is an XP system that it won't work? ph Grandma, "Granny does your computer's chip have hardware support for ..." etc.
+++

I'm suggesting keep people informed, build a generalized SW and HW framework for the now inevitable OS and kit dropoffs and see what fancy bits become asked for rather than second guessing on the fly earlier or later compatibilities because of a current system.

Wm

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
XP Only

This would only be for XP. And it's really a small minority of users that are still using it. Plus there are only 3 apps (under 1%) that have dropped XP so far. If someone updates and later finds themself on an XP system, they can then add the legacy version if they want when prompted. It will be insecure, unsupported, etc, and warned of as such.

It's hard enough to support apps as it is without making it more complicated.

Sometimes, the impossible can become possible, if you're awesome!

Wm ...
Offline
Last seen: 7 years 2 months ago
Joined: 2010-07-17 12:37
As one of the XP onlies

cough, gasp.

As I said at the top, I'm OK with a list.

I'm aware of what I am running and why.

You won't see me complaining unless there is a big surprise.

Wm

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
Sounds good to me.

That sounds like a good plan to me.
I'm wondering however if this would be an XP only thing? or would it also be done for Win2K, etc.?

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Ditching 2K

We're ditching 2K. It's barely used and most apps no longer support it. Windows XP is still widely used.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
Aww   :'-(                   Implementation details?

Poor Win2K, this makes me very sad.
I would think you'd want to make it a reusable system, in case Vista (not likely) or Se7en (more likely) decide to hang on like XP has, in which case adding 'Legacy Win2K' support wouldn't be much more of a burden then adding 'Legacy XP' support already is.
(I'll make 'Legacy Win2K' Plugins [see below] for you if that'll help to change your mind.)

I'm thinking about the implementation details:
Would you simply install the 'Legacy XP' PAF next to the current one (e.g. X:\PortableApps\FileZillaPortableLegacyXP) or would you go for something more integrated, like a 'Legacy XP' Plugin Installer that would place the old version in a dedicated place in the current PAF (e.g. …\FileZillaPortable\App\filezillaLegacyXP\*) and tell the Launcher to use it (and supply the appropriate warnings) when running on XP, informing the user that they'll need to get the 'Legacy XP Plugin' to be able to use it on XP (in case they launch the PA.c launcher without the Platform).

I can also help with getting PAL ready for 'Legacy [WinVer]' Plugins if you'd like.

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Platform Is Easy, Apps Are Not

Adding it to the platform is the easy part, so it's reusable if that were to happen in the future. It won't, though. Vista only has 3% and falling overall marketshare online. And it's supported through 2017. Windows 2000 was on a similar trajectory towards the end and is only at 0.02% now. XP is a complete anomaly for a number of reasons.

While the platform is easy, the apps are not. Going through all the apps and determining which version last worked on Win2K and then packaging AppNamePortableLegacyWin2000 versions for every single one and then adding all of them to the database... it's not happening. And it's not worth it. Most of those versions are so old and insecure you should absolutely not be using them for the major app types (browser, office suite, email, IM), which is what people are usually looking for.

For a larger discussion in Windows 2000 support, please see and reply here: https://portableapps.com/blogs/johnhaller/2014-09-25--thoughts-on-ending...

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
As it comes up? ; What do you think of LegacyWin[Ver] Plugins?

I thought you said you were planning to deal with Apps that no longer support XP 'as users report them', 'LegacyWin2000' Apps could be dealt with similarly (albeit with lower priority)
Also I'm volunteering to do the 'LegacyWin2000' packaging for you, so it's not like I'm asking you to do all that much, it would only be one more release per Legacy app, and since some apps are dropping Win2K at the same time as WinXP wouldn't it be better to call them 'LegacyWin2000' than 'LegacyWinXP' as WinXP supports most Win2000 apps? this way we don't unnecessarily cut Win2K users off from Legacy apps that would work for them too.

Anyway, that's all a side issue, the main one being the implementation details I asked about. What do you think of the LegacyWin[Ver] Plugin idea? Again, I can help get it implemented and ready for release if you'd like.

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Too Much Time, Platform Dropping

First, we're dropping Windows 2000 support in the platform, so they won't even have access to the ability to download alternate versions by the platform, rendering the alternate packages moot.

Second, even if we did tie ourselves to the dead Delphi XE2 release in order to keep supporting Windows 2000, the bigger issue is time. At present, all releases have to be reviewed, digitally signed, uploaded, and added to the database by me. I'm not going to spend time doing that for the 150 apps in our database that dropped Windows 2000 support 1 or more years ago.

Windows 2000 users have no active support from most apps right now, so it's not like they're losing anything. Windows 2000 also has barely any userbase.

Windows XP is a very different situation. There are probably more Windows XP users today than there were Windows 2000 users 3 years before it was end of lifed. And the majority of apps today support Windows XP. So, this is a small amount of work for the handful of apps dropping Windows XP support that we'd have to test for anyway for a benefit for a good number of users. Windows 2000 is a ton of work for a handful of users for very old and insecure versions of apps.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
Why do people tend to not notice the important part?

The Windows 2000 stuff was a side issue from the moment I mentioned it, I didn't mean for it to be responded to in anything more than "I'll consider it", or "No", or I possibly "Let's talk about it in the Windows 2000 thread." I'm sorry I brought it up.
Either way, I'm willing to do any work you can delegate to me if you ever decide to work Windows 2000 support in.

The main point in these posts was to offer the Legacy app version Plugin Installer idea. Did you read it? What do you think of it?
Again, I'm willing to help out in getting it implemented and ready for release if you want to do things that way, just let me know.

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not Really Needed

I answered what you asked. And you did have 2000 or 2K 5 different times in your post.

My point was that it would only serve Windows 2000 right now, which doesn't make sense because it's barely used, would require a ton of effort to sort through the apps for little benefit, and the platform will be dropping support for it anyway which makes it moot. We don't need to worry about Vista until 2017... and then not much at all since it's the ugly stepchild with hardly any users. So, Windows 7 in 2020 is the likelier bet due to the large installbase and the fact that desktops get replaced much less often than 10 years ago.

Vista and up share quite a few things in common in terms of the kernel, so it's unlikely that a given app will drop Vista anytime soon if it already supports it. Granted, many more modern apps only test for and list support for Windows 7 and up since Vista is barely used. So, it's far more likely that a new app won't support Vista at all than an existing app we package dropping support for Vista.

Basically, my overall point is that it's not worth the effort to setup a plugin-based system that wouldn't really see much use for the next 6 years. XP being dropped is really the only thing we need to worry about due to it's very unique position as being end of lifed but still widely used. In the off chance we need to worry about Vista in 3 years, it will only take about 15 minutes to adapt the code to work with it as well. So, spending all the extra time now to implement it and test it isn't really well-served.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
What do you meant "only serve Windows 2000 right now"?

How would it not serve Windows XP to have the Legacy version for Windows XP support be inside the current PAF folder structure and use the same Data folder?
My reason for thinking up the Legacy Plugin idea was to prevent the "I changed that setting, why isn't it working … OH, I changed it on an XP machine so now that I'm on a Vista machine it's using a different set of settings" situation.

If we ignore Windows 2000, Windows Vista, Windows 7, etc. I still think that a system of Legacy Windows Version Support Plugins is better for the end user, and not all that much harder to set up then a secondary full-blown Legacy install.
Again, I'm offering to help implement it too.

So, focusing on XP, What do you think of using the system?

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Messy

I'm not going to adjust the PAF structure for dead OSes. Rewriting PAL to work from multiple locations and then rewriting PAI to handle multiple apps installed in the same folder and then rewriting the platform to understand it is a lot of work for hardly any benefit. And yes, we would need to rewrite all 3 to handle things in this fashion. Or move the data back and forth between installs which introduces its own issues. And then support and make bug fixes to it forever. We don't even currently have any active developers that understand all of PAL.

We have far bigger fish to fry.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
You're already talking about

You're already talking about changing the Platform "to prompt users when they attempt to run a Vista and up app on an XP machine", and Updater "to automatically download and install the XP-only" version. I see little difference in also adding a check to see if the Legacy Plugin is installed (could make the Plugin add a LegacyXP.ini file in AppInfo that the Platform could check for) and if present have it launch the appinfo:[Control]:Start (or Start#) entry as normal, letting the Launcher handle (see below) the Legacy version.

The Installer would require no code changes because Plugin Installers are already supported. Of course there are improvements that could be made, but the only necessary change would be to add entries in each App's installer.ini to prevent the Legacy version's files from being deleted when updating the current version.

And I don't think it's all that much work to add a launcher.ini:[Launch]:ProgramExecutableLegacyXP, a check for XP, a check for the presence of the file referenced by ProgramExecutableLegacyXP, and a dialog box informing the user that XP is not supported by this App and if they need/want to use it they need to get the Legacy XP Plugin, it could also state that this can be done automatically if launched from the Platform. I'll do it if you like.

Edit1: You're also already talking about changing the PA.c Format to advertise the Minimum OS version (e.g. AppInfo.ini:[Details]:MinOS) so adding a method for the Plugin to advertise Legacy XP support (e.g. AppInfo\LegacyXP.ini) could be done at the same time.

Edit2: I have a pretty good working knowledge of how PAL works, I've made changes for my own (unpublished) PortableApps numerous times over the years.

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
No

Plugin installers are a bit of a hack and not handled by the updater. Or the platform. Or anything else. They're just a simple hack to add a few files to a given app. Then the installer.ini for each app needs to be manually adjusted to preserve the files that are added for the plugin. They're entirely un-automated.

It is absolutely not as simple as adding a single entry to the launcher.ini. Files need to be moved around, directories are sometimes custom coded in custom.nsh for a given app's PAL. PAL doesn't even support a separate 64-bit path at present (it must be done in custom code), adding in a fully independent app as well would be even messier. PAL would need some pretty big changes to support 4 independent directories (32, 64, legacy 32, legacy 64, etc).

And then, again, that app, as it's updated, would need to check for and ensure that the XP files are preserved and that a given version of an app didn't break the settings files or update them to be incompatible with the dead XP version of the app that's still hanging around. Settings files in apps change all the time, often in ways that are not backwards compatible. Or, they store the version of the app in the settings and perform specific 'upgrade' processes on settings as you move from an old version to a new one. So, for every app that we did an XP plugin for, we'd need to ensure that the settings worked under both the dead XP version and the current Vista+ version and still worked as you switched back and forth. And by we, I mean me, since all this testing falls on me. There's no way I'm committing myself to years of that misery. This is the issue here that's a dealbreaker for your concept.

The only minor thing I'd be willing to add is a one time release of an AppNamePortableLegacyXP that the main app can completely ignore the existence of. That would require fairly minor changes to the platform (if app is Vista+, running on XP, and has an XP version available, offer to download) and the updater (accept a given input to automatically download and install a file which we're implementing for other purposes anyway). It won't require any changes at all to PAL or PAI. And, again, I'm not even sure I want to implement this time-wise, support-wise, etc.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
OK

LegacyWinVer Plugins wouldn't need to be updated would they?
But yeah, I'd forgotten about future settings possibly losing backwards compatibility, if that weren't an issue I still think my plan would have been pretty good :(, thanks for bringing it up.

I guess the appropriate thing to do then is to make the (separate) LegacyXP version (ask to?) import settings from the current version if it's Data folder is empty and the current version's isn't? This should be able to be added to PAL via Custom Code (or more fully integrated if you'd prefer).

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
They Might, Bigger Issue

They might need to be updated if we alter PAL or really make any future changes. It's a mess of stuff to keep straight and review. Heck, we just had a dev mess up yesterday and configure an update to remove the Data directory of an app. I had to push out a PAI update as well to remove that feature so other devs don't mess up.

Remember, we'll have all sorts of publishers and devs using and doing things that won't read the spec or will make mistakes.

The bigger killer is settings compatibility, of course. It's something you learn about the way apps work after having to deal with it for 10 years. I just always assume people are familiar with the issue since it's bitten me in the ass so many times.

As for LegacyXP, I may do custom code in the installer to pull it in rather than in PAL.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
 

The issue with doing it in PAI is that it will (obviously) only occur when the app is first installed. If it's done in PAL then the it can ask to import again if the user deletes the Data folder, making for an easy way to update your LegacyXP settings to match the current version's in cases where the settings are still compatible. Of course, if you don't see this as an issue then PAI's Custom Code will work fine.

Also I get what you're saying about mistakes, but the …\AppInfo\LegacyWinVer.ini I mentioned could have easily include a 'PackageVersion' string for the Legacy Install which could be checked by the Updater if necessary.

I forget sometimes that other devs don't try to keep their settings backwards compatible because I usually try to make things right from the start so that I won't have to change them later.

Also the development version of PAL supports separate 64-bit directories quite nicely with the PAL:Bits environment variable.
BTW: Do we have a checklist somewhere of what needs to be in the next release of PAL? (if so I can try to work on it)

~3D1T0R

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 4 months 1 week ago
DeveloperModerator
Joined: 2008-07-24 18:46
Slightly OT

Re: checklist - Not unless John has one. As I'm able, I'm trying to attack the ongoing bugs for PAL, but I'm not 100% that those are blocking a release.

Also, if we put out a legacy xp version, rather than including an additional INI, the data directory would be reset when deleted, like normal.

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
Not related

The INI I was referring to was a part of the LegacyWinVer Plugin idea which John has rejected, I was just clarifying one point of it; it has nothing to do with resetting Data or not.

I'll make a new topic asking what needs to be in the next version of PAL, so we can all discuss it further there.

~3D1T0R

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Same Issue

The problem with doing it in PAL is that we face the same issue. If we import at install, it'll likely work. If we import when they reset it a year from now, it probably won't. Plus, some of the apps won't be in PAL and I'm not going to rewrite them just for this. PAI custom code is reusable on every app.

PS - I forgot about Bits being added to PAL 2.2. All the dual mode apps are still configured for PAL 2.1.

PPS - Sadly PAL:Bits doesn't work in PAL 2.2.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 2 years 8 months ago
Developer
Joined: 2006-12-29 23:48
Fair

That's a good point for doing it in PAI.

~3D1T0R

Wm ...
Offline
Last seen: 7 years 2 months ago
Joined: 2010-07-17 12:37
PAE and NX as well as SSE2 ?

Background: the issue of PAE and NX as well as SSE2 has arisen in another forum regarding a non-portable legacy app working or not on Win 8.n on certain kit.

This article says what PAE, NX and SSE2 are from one POV
http://windows.microsoft.com/en-GB/windows-8/what-is-pae-nx-sse2

The article states NX requires PAE but the relation to SSE2 isn't obvious (to me and some other people).

WRT any given PA app is the processor support check :

SSE2 (by def includes PAE and NX)

or

SSE2 and PAE (by def includes NX)

or

SSE2 and PAE and NX

or some other combination of the above.

I don't know of a PA where these edge cases might kick in but I can't find anything that says they won't and
http://en.wikipedia.org/wiki/Physical_Address_Extension
seems to suggest nobody else really knows either.

If there is something definitive on this that we can all read or look at (a matrix would be nice) feel free to point it out.

Wm

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 52 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Quite a Bit Different

Windows 8.1 itself won't run on a CPU/BIOS without PAE, NS and SSE2, so that's unrelated to portable apps.

NX support is used by the OS, not by apps themselves, so we don't need to worry about that.

PAE is used by the OS to allow a 32-bit processor to access more than 4GB of RAM. None of our apps need it.

If, in the exceedingly rare instance an app we add needs over 4GB of RAM and requires PAE to run, we'll add it.

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments