We've been discussing the idea to make it an advanced option for users to select whether they want only the 32-bit version, only the 64-bit version or both (aka dual mode) for apps where we do automatic switching for a while now. Apps like Firefox and 7-Zip where we currently include both versions and have the launcher automatically switch between them. There are quite a few things to keep in mind while considering this:
- Dual mode shared directories: Some dual mode apps apps do specialized handling of certain files that are shared between the 32-bit and 64-bit versions of the app to save space. Blender, for instance, moves the datafiles back and forth between the two to save 68MB in installed space (note that this is mistakenly included twice in the 2.79 release, though). This won't work with the standard structure of NSIS installers where we'd only install the 32-bit directory or the 64-bit version, so we'll need special handling for these. Possibly Blender, Blender64, and BlenderShared as the 3 directories installed where Shared is installed regardless of selection and moved to the appropriate location as it installs.
- Standardize directories: We'll likely need to standardize on directory layouts for ease of coding and maintenance. This will likely be as App\AppName and App\AppName64 for the 32-bit and 64-bit versions respectively
- Online installers: We'll have to rework the way online installers that download the 32-bit and 64-bit versions of an app are currently handled to work with this
- 32-bit only apps: Some apps we distribute as 32-bit only and these selections won't be available for them. These apps there's no real advantage to running 64-bit so they'll continue to be packaged as is as per our standard 64-bit apps policy. Adding 64-bit to these would double the download size and default install size for no real benefit.
- Eliminate Optionals: We'll likely either eliminate the ability to have optional components in installers or make it so installers can either have optional components or do the selectable 32/64/both setup to avoid conflicts in handling the UI
- Not Shown By Default: We'll avoid showing this to end users by default. There's a reason most software handles this automatically (either automatically showing giving the user a download button for only 32-bit or 64-bit based on their current OS or downloading just a stub installer that automatically downloads the right one for their OS). The reason is that most users don't know what 32-bit vs 64-bit is. And within an installer is not the place to try to explain it. Of course, most of the folks posting in the forums here know the difference, being advanced users. But we're not the majority of the folks that use our software. Users that come across something they don't understand have a tendency to click back or close and feel dumb/unsure or not trust the thing they're using in the process. So, we'll likely hide this by default and either give users an advanced install option** where the selection is or we'll hide it entirely by default unless the user starts the installer with a specific option (think holding down the SHIFT key while the installer starts or starting it with --advanced on the command line). Maybe even a registry key or environment variable on a given PC so advanced local users that don't use the platform can set it once.
- Automated Platform Integration: We'll add an option to the Advanced tab in the platform's options to select Both, 32, or 64 with Both being the default (as many users either use it portably on multiple machines or move it around using synced cloud folders). This will be handled automatically in the installer with no need to bother the user on each install/update
- PAL and Launcher Updates: We'll need to update both PAL and custom launchers to handle either 32-bit or 64-bit being missing. Some currently look at 32 first and throw an error.
** Advanced Installer Note: I'd like to avoid having installers have an advanced option visible by default. The reason is that the only time you'll see an advanced installer these days outside a handful of open source apps is when an app is trying to hide bundleware. Bundleware is set to install by default and the ability to turn it off is hidden behind an "Advanced", "Custom Install", or "More" selection the user must make. For example, CCleaner's installer a couple weeks ago was installing Chrome and setting it as your default browser automatically on installs with no notice unless you happen to click the tiny "More" button where it told you it was doing that. While you and I both know that PortableApps.com has never done bundleware and is trustworthy, not everyone who downloads our software will know that.
So, what's everybody's feedback and thoughts? This is a rather large undertaking to first update all the tools and then update the individual apps. We may take the low-hanging fruit first (apps that bundle both already) and work up to the more advanced ones later (online installers) to start getting these out as well.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I understand that many people don't understand the difference and that we should try not to confuse them, however I think that if it's done right, PAF installers can be the perfect place to explain the difference, as it pertains to PortableApps.com apps.
In particular, I envision it on a new page in the installer using radio buttons.
Perhaps the descriptions could use a bit more tweaking, but something like this:
(•) 32/64-bit hybrid (recommended) This option is the default. It includes native binaries for 32-bit and 64-bit versions of Windows, the app will run on both platforms, and automatically choose the best one to run each time it is launched. ( ) 32-bit only This option only includes 32-bit binaries, which are compatible with both 32 & 64-bit versions of Windows but will not make full use of a 64-bit system's computing power and memory. ( ) 64-bit only (experimental) Important: If chosen, the app will only function when run on 64-bit Windows This option only includes 64-bin binaries, which are NOT compatible with 32-bit versions of Windows. If you aren't absolutely certain you want this, you probably don't.Note: It would probably be a good idea to have "(recommended)" and "(experimental)" be in red text.
Also, if you're really concerned about it, the "64-bit only" option could be disabled ("greyed out") if the user is on a 32-bit machine and/or pop up an 'are you sure' message if they choose "64-bit only".
~3D1T0R
Unfortunately, those 5 sentences don't explain what 32-bit or 64-bit means. Remember, you're going to have users install it who don't know what version of Windows they use, let alone understanding what bit depth is. That's also a ton of verbiage to have on a single page of an installer. It wouldn't fit in either of the standard NSIS options page layouts and would require a custom page with the entire page filled with text to fit. And it would still leave users confused.
It's basically impossible to explain what 32-bit and 64-bit mean within an installer, so showing them as options to normal people is a bad idea. They would have to be buried within an Advanced Install option, but that leads to the issue mentioned above about it feeling bundleware-y.
Sometimes, the impossible can become possible, if you're awesome!
I don't think we need to explain what 32-bit and/or 64-bit mean, as in explaining the architectural differences. If they want to know more, they'll look it up. What we need to explain is how the choice effects them. That's what they need be able to understand, if they bother to care.
My personal experience with non-technical users points to most users simply accepting the defaults when running an installer, so we should have the hybrid version be the default. Also, I really don't see why you want to hide it at all, I sincerely doubt that adding another page to the installer containing something along the lines of what I've written in my previous comment would 'scare away' many, if any, potential users, and I think many (most?) who would otherwise be scared away will see the red "(recommended)" on the default option and have their fears abated.
~3D1T0R
I agree with this. Users who don't understand something will Google it. This is what I did when I first encountered architecture and I've never had someone just close out of an installer because they were confused. If they went as far as downloading the installer than they went with the default options. Which is why you fear "bundleware" so much because people go with defaults; not back out.
daemon.devin
Are we really suggesting that first time users of our apps should be using Google to learn what an install option means? That's an awful lot of friction.
Sometimes, the impossible can become possible, if you're awesome!
No but if they're anything like me they will search about it because that's exactly what I did. As Google seems to know everything and most everyone knows what Google is and have Google at their fingertips, is it so far fetched for a user to look something up?
daemon.devin
If they're technically advanced enough users to care what the architectural difference is between x86 and x86_64, they probably already know, or they'll look it up on their own. If they aren't the kind of person who cares enough to look it up, then text along the lines of what I wrote above will explain enough information for them to make the right choice, if they even bother to consider changing from the defaults.
I don't think it's quite as big of an issue as you seem to think it is. Other than actually adding the functionality into PAI, the biggest obstacle I see at the moment is that PAL needs to fully support operating from all three modes of installation (including a well worded and informative error message for when someone tries to run a 64-bit only install on a 32-bit machine), and (as you stated in the OP) we'll need to start packaging things differently to be compatible with that.
~3D1T0R
Quoted 3D1T0R:
This was my point to begin with.
Quoted 3D1T0R:
Yup. To start with I think PAL should check for architecture inside the
.onInitfunction in thePortableApps.comLauncher.nsifile. I also feel it should check for administrative rights here too but that is a different topic. Note the following:This way we can check bit depth before even the Custom segment is run which is how I'm able to do the following in my version of 7-Zip Portable in the
custom.nshfile. I've added new code to support what @3D1T0R had suggested about an error message when trying to run a 64-bit app on a 32-bit machine. This is just a concept of how I think this could be handled. Note the following:Notice how I use
7-Zipand7-Zip64as the declarations for the variable$App. If I remember correctly, this is how @JohnTHaller would like to standardize this concept for folder structure (it's also the way I structure it too). Of course,$(WrongBitDepth)is the multilingual string definition which would be theLangStringplaceholder for whatever the error message would be denoting the wrong bit depth.I'm not suggesting that this should be the method in which this concept should be done. I'm merely showing how this concept can be done. It's a work in progress anyway.
daemon.devin
This Is the Direction in my opinion.
Maybe even harsher when presenting the default:
(•) 32/64-bit hybrid (Recommended / Default)
This option is the default. It will work on any Windows Computer.
Choose this unless you know specifically what you're doing.
( ) 32-bit only
This option only includes 32-bit binaries, which are compatible with both 32
& 64-bit versions of Windows but will not make full use of a 64-bit system's
computing power and memory.
( ) 64-bit only (experimental)
Important: If chosen, the app will only function when run on 64-bit Windows
This option only includes 64-bin binaries, which are NOT compatible with
32-bit versions of Windows. If you aren't absolutely certain you want this,
you probably don't.
This is a good way to portray to the end-user what their options are.
daemon.devin
Relegate the jargon to a small point at the end that advanced users will understand despite its brevity, then simplify the language of the main point to the minimal data that needs to be conveyed, and do it in plain language. Something along the lines of:
(•) Hybrid (recommended) Runs on all systems, occupies more space on drive, may use more system resources to run faster (Installs 32-bit + 64-bit packages) ( ) Compact Runs on all systems, occupies less space on drive, may run slower on some systems (Installs 32-bit package only) ( ) Edge (Advanced users only) Will not run on all systems, occupies less space on drive, runs optimally on compatible systems (Installs 64-bit package only)It's worth noting that, as a general rule, there is no performance advantage to 64-bit packages for over 90% of apps in my experience and independent testing. The exception is specific CPU-bound activities and even then only when an app has been decently optimized specifically for 64-bit. That's why browsers see an advantage but only when using a Javascript-heavy page or why we bundle 7-Zip in dual mode since it gets about a 8-9% advantage when compressing larger file sets. Although, the only times we'll be bundling both is when there is an advantage either speed or features (opening 1GB+ text files in a text editor for instance).
Sometimes, the impossible can become possible, if you're awesome!
That's exactly why I used the word "may" - some users might see a benefit, others might not, depending on usage and some other factors.
That's not "dejargonized", you've just come up with new jargon that would be PA.c specific.
~3D1T0R
I don't understand how "Runs on all systems, occupies more space on drive, may use more system resources to run faster" could be construed as jargon in any way.
If you are talking about the title of each option, hybrid is a term we already use at times but maybe dual-mode is just as appropriate. Compact is in no way jargon, just a plain-English single word description that (in my opinion) best fits what the option means without going into architectural considerations. And more than likely there are better terms than Edge, it is just what I can up with on-the-fly.
I personally have no attachment to the specific wording I gave, I was just suggesting a much more user-friendly, plain English, descriptive turn of phrase over the more verbose architectural descriptions that will go over the heads of a subset of our user base.
He doesn't know what he is talking about. He believes if he contradicts a good idea he'll sound smart.
Your depiction was the best one thus far.
daemon.devin
Please no purposely antagonistic personal remarks. It runs afoul of the play nice policy.
Sometimes, the impossible can become possible, if you're awesome!
And you think this was in accordance with your play nice policies?
John, I'd like to refer you to the last paragraph in this comment. I will not stand for his asinine attempts to make people feel stupid. It only back fires on him. I will not stop as long as he continues his disregard for other people. I'm sorry but if you feel the need to handle this by banning me than so be it. You would probably be doing me a favor anyway seeing as my efforts are still going unheeded.
daemon.devin
Even if you don't like the tone or agree with it, the other poster was making a logical point that can be argued (Hybrid, Compact, Edge are new terms that aren't generally known to mean what they're representing here). Your response was a personal attack:
That runs afoul of the play nice policy. Please stop.
Sometimes, the impossible can become possible, if you're awesome!
I was mainly referring to 'edge' in particular, but I don't see why the options need to be given English names when 32-bit and 64-bit are what they are. I suppose I don't mind calling the 32-bit only option "compact", but if we name one, we have to have a good name for the 64-bit only option, and I feel "edge" is a poor choice.
~3D1T0R
What's wrong with edge?
Edge-case scenario or bleeding-edge technology.
While there might be a better term for this, this one still works.
daemon.devin
Is it readily apparent on a quick read what it means? Will it translate well into 72 different locales?
Sometimes, the impossible can become possible, if you're awesome!
You're right. I wasn't factoring the slang in other languages.
daemon.devin
I'm personally not in favour of offering the ability of installing only 64-bit applications in this manner.
The main reason is due to the inevitable support queries: "xyzPortable isn't working for me", which turns out to be an attempt to use a 64-bit application on a 32-bit system. Yes, I am aware the idea is to label the option in some way to indicate this is an "advanced user" install, however human nature says some users may try to use it anyway because it's offered. We would then have to deal with the above-mentioned support scenario.
With that said, assuming we go ahead with this, here are my thoughts on the above points:
I am on principle against hidden install options, especially ones that are as well hidden as what you're suggesting. If it's an available option, I feel it should be a visibly available choice for any user who downloads and executes the installer. If it's too advanced for 'average Joe' to fully understand, then it should have a default setting and some simplified description(s) which help him make the right choice instead of being hidden from him, let alone the idea of it being hidden entirely like you guys are discussing.
~3D1T0R
I agree with this fully. Hiding something from an end-user would likely leave them feeling something shifty is at play even though there isn't. It's like you said with the bundleware problem; users will just exit out and not bother.
daemon.devin
My issue with it is not so much about someone seeing that there's something hidden and thinking something's shifty. It's more about people who may be interested in using the option not having it offered to them. I see little point to making the choice available at all if it's not offered to the user when they run the installer.
~3D1T0R
I was only using what you said to prove one of my points to what John was saying in another thread. You know, the one where I made the installer for 7-Zip do exactly what you just said here. The whole reason John started this thread was because I felt that people would be interested in having the option offered to them.
Portion of comment removed for violating Play Nice portion of forum guidelines. - mod GC
daemon.devin
Devin, stop. it does not help anyone to continue adding these inflammatory comments.
If you say so.
I would think what I had said earlier would have warranted removal more so than the question I had just asked him. Lol.
daemon.devin
As far as I can tell, the issue you mentioned has already been addressed. Nobody on here has indicated in any way that they have any issue with John's statement that making the option available in a semi-hidden 'advanced options' (or similar) section is a bad idea because people are likely to think there's something fishy going on. I agree, that's not a good thing to do.
By making a post saying "I agree" and then writing about a different issue you're drawing attention away from the issue I'm bringing up. It's nothing to do with being with or against anyone else, I'm just trying to point out an issue, and you directed the conversation away from it, so I made a post stating that that's a different issue.
So... Can we be done with this already?
~3D1T0R
I was expanding on your issue as it can be related to what I was saying before.
I admire your guys' tenacity. XD
daemon.devin
I followed this discussion for a while now and I personally disapprove the idea to present these options to the end user during the install process. I even think, in everyday use the benefits of these options are largely theoretical (and I was always prone to optimize my setup).
For example: I maintain the it-equipment at my school and when I think of my collegues, a great many of them would be very uncertain what to do even if there is a reasonable explanation for a default option. Not that most of them use portable apps, but they could. They would never even see a benefit in these options even if they could be persuaded to look them up.
I think, we really don't need a prominent location for such a niche option. Maybe an optional script hidden in the source folder, that could be manually "activated" to delete the unwanted part could do the same trick (it may not be as elegant).
I consider it much better to keep the installer as simple as it is. Even now some people visit the forum for an an explanation, why a simple "portable" app needs an "installer" whereas they think, both options are mutually exclusive. More options would possibly render more people suspicious.
The only end user benefit is decreased install size. Users already get the best fit version for every PC they run on. The only thing that this option would save is install space for users that only use something on Windows x64 or who are in a space crunch and use multiple PCs but want to stick to 32-bit only.
Sometimes, the impossible can become possible, if you're awesome!
Yes, I know. But space is mostly not the limiting factor these days. I don't know, if pendrives smaller than 2GB are anymore in production, most quality brands have no drives smaller than 8GB.
I can imagine there are a lot of people without access to bigger pendrives, but maybe they are not the target group of this option.
I have been a space-saver in former times. I deleted unused locales of gimp and many other apps and even wrote some scripts for that. But I stopped that years ago when pendrives grew so much faster than the space requirements. I think the first drive I used portable apps on was a 128MB no name drive from a discounter.
But nowadays I don't even waste a thought on such things as my PA.c folder simply fits on all my drives even with space hogs like LibreOffice, Krita, Shotcut, Stellarium and Inkscape. And I am an app collector...
That's why I considered the benefits largely theoretical.
When thinking about space, don't think flash drives anymore. Think synced cloud folders. Most people only have the free version which is 2GB, 5GB or 15GB across the most popular providers.
Sometimes, the impossible can become possible, if you're awesome!
Ok, totally forgot about that (don't use cloud that much beause I only have one main computer at home and work on a lot of others without sync options),
Hey, now there's an idea. If we make sure PAL will be fully functional with either the 32 or 64 bit version missing, we could just include a small batch script that people could run that removes one or the other (ensuring at least one remains).
~3D1T0R
My main objection is confusing the majority of users who don't understand it. But installing and then manually removing seems like unnecessary work for users who want this. Plus, it's wasted time as the installer has to install something that the end user is going to delete anyway. Ideally, we'd build this into PAL and PAI and have an option at the platform level as well as at the PC level (env var or reg key) to trigger it globally as well as individually per install with a command line switch. Users could of course just delete the AppName or AppName64 directories as well.
Sometimes, the impossible can become possible, if you're awesome!
My issue with what you're suggesting is that we make an install option, then don't offer it to our users. That just doesn't sit well with me.
If we're going to bother writing the option into the PA.c Installer, I feel that the installation wizard should offer it as an option.
I understand that it's an option for more advanced users, so I could see placing it in a semi-hidden portion of a page of the installer which shows click an "Advanced Options" button, but you've made it clear that you don't like that idea, and have provided good reasons not to go that route, so that's a bit of a moot point. The way I feel would be best is to simply not hide it, but you refuse to accept this. So, I suppose the only other option is to have it in full view, on a page that only appears if launched in a special way (like holding the "SHIFT" key, as you mentioned in the OP). Thus I guess we should ask how feasible it is to detect whether a user is holding SHIFT while launching the installer? I wouldn't think it would be too difficult, but I'm only on my phone at the moment and can't check it out.
And finally ... for anyone who didn't catch all of that: I believe the idea is that it should work similarly to how you can start Firefox in 'safe mode' by holding the SHIFT key while launching it, so... Does anyone have a problem with this plan?
~3D1T0R
I think I have another option which should be discussed.
But on top of that, please don't think the only use case of PortableApps is on removable media.
I use it for all my applications (I only use Portable Applications) which helps me keep Windows like on its installation day.
Another remark, you either treat user as they don't know anything (Next -> Next -> Next) or they know what they do.
On the first option it means if we introduce the screen of choice those who don't know will just click Next and everything as it is today.
Those who understand will make a wise choice.
Some will make mistakes, but let's not design by 0.01% of users but according to the most.
That being said I would like to add another option.
Have 32 / 64 Installers and put the selection of what to download in the PortableApps options menu (There are many "Advanced" options there).
I will tell you what the advantage, I like to run 2 instances of Chrome so being able to have 32 and 64 in parallel is great.
So my model is the same as we have for Chrome (I wish it was for Firefox as well).
This reduce the amount of data to download and allow more flxibility to the user and approaches advanced users by the option menu of the suite application.
So have them both as different application on the suite.
User can make the default selection in PortableApps application (The Start Application) and those who would like to have both will be able to do so.
The option should be something like "Show 64 Bit application in Download List" and then the user can install it as any other application.
Thank You.
The problem with that is - That's just not the case. There are no two groups of users but a whole bandwidth. I don't know, if you can imagine what different ideas "uninterested" users can have of how to deal with a challenging task (like installing an app). Many somehow manage to install it anywhere (next, next, next does work for some of them). But people get involved at different stages. Many want to change something, simply because there is an option. I found configurations where different apps were installed in the same folder or simply as a total mess in the root folder.
The worst case is when people think they know what they do to a certain point but than stop without remembering what they did and how.
To cut a long story short - people who are interested and willing to learn will have no problem with additional options but there is a whole bunch of users out there who simply consider working with computers as burdensome but necessary task. Not all of them will ignore portable apps. Any additional option they stumble upon might scare them away.
We are not here for them and they probably do not even know about this website nor care to find a place like this. Like Drazick had said, we should not be designing what we do around these people but be working for those who are interested in what we offer.
daemon.devin
You say we should be careful of "of users out there who simply consider working with computers as burdensome but necessary task.".
Those people, who consider working with computers, do they use PortableApps?
Were not talking about Microsoft's Applications.
People who get PortableApps need to hear about the idea of Portable Application in Windows.
Need to be aware of a site named PortableApps.
Need to download a suit and chose type of installation (4 options which are far more complex).
Please, this is not the profile.
PortableApps user is well above the basic user of Windows, let's treat him like that.
But anyhow, my suggestion, embracing the model of Google Chrome in PortableApps (Different installers, the site put the regular 32 Bit as the default) and having option to display 64 Bit apps in the PortableApps Suite Launcher options seems to me something which gets all the advantages and almost no disadvantage.
Chrome's default download page just shows a Download button (with no details on 32/64 etc) and then you click through to a license agreement where it says Windows 7/8/10 64-bit with no option to switch it and no mention that there is any other version available. Essentially, Google is detecting what version of Windows you're running via your useragent and then giving you the matching version of Chrome. If you're on Windows 64-bit and you want Chrome 32-bit, you need to manually search Google for the Chrome channels page.
Sometimes, the impossible can become possible, if you're awesome!
I was talking about the model of Chrome in PortableApps:
1. 2 Installers per application - 32 Bit (Default on the webpage in PortableApps) and 64 Bit (Almost hidden in the webpage). Exactly like Portable Chrome page in PortableApps website.
2. Adding support in PortableApps application (PA.c, is that the name?) in the options menu to "Show 64 Bit installations". If I chose to enable it when I look on lists of application form PAc (Apps -> Get More Apps...) I will se 64 Bit installers.
3. One could have 64 Bit version installed next to 32 bit version.
Thank You.
The only reason this is currently done is technical. Chrome uses an old ANSI NSIS custom launcher and would need some recoding to handle 32-bit and 64-bit automatic mode. If it was using PAL, it'd be dual mode for all 3 Chrome channels.
Sometimes, the impossible can become possible, if you're awesome!
Yes, you told me once about that.
Please don't merge them.
It is the only sane way to have 2 instances of Chrome which doesn't share Cookies.
Please leave them apart.
I personally know a few non-technological people who started using PortableApps.com apps prior to having visited the site because the platform and some apps came pre-installed on a USB flash drive, so you really can't assume everyone who comes to PortableApps.com is an Advanced user, they may just be checking to see if there's anything new from "the people who made the program my USB came with". (Yes, I've actually heard people say things like that about PortableApps.)
~3D1T0R
We need to look on the people who install it, not using it.
All my friends use PortableApps because I installed it on their computer (Again, not a USB Drive, in the main drive, see my writing above).
PortableApps, by its functionality doesn't require advanced user, but usually its users are a little above regular users.
Why not? Not all of them are uninformed. Some of those people happen to use portable apps simply because they got a recommendation to do so (either from friends, from magazines, I even read about portable apps in a lifestyle column). Or, the PA.c-Platform sometimes is chosen by tech-staff to equip people with an easy access to a more or less consistent app base (locally or portable) just because of the ease of (self-)updating and installing. Or people get the idea to carry a set of apps for their work (office, browser, mail, translator etc.) with them. Maybe they manage to use and update it in daily work, but they don't want to make technical decisions.
From a technical point of view, the option to chose between 32/64 may be very interesting. If it's hidden by default and managed from the PA.c platform, I'm totally ok with that, but every other way would shove PortableApps.com a good way into the nerdy techie direction.
Sometimes it may be good to step aside from ones own preferences and try to look through some other peoples eyes. While the forum here is mostly an aggregation of techies, I really doubt, the userbase is the same.
Just one more personal example: My teammate is one of the most unexperienced pc-users, I ever encountered. But she uses LibreOfficePortable, can update it on her own and even install it from scratch (- if the platform is already there...). She would not install the local version on her own simply because of too many decisions.
Hosting a 32-bit installer and a 64-bit installer separately just isn't going to happen. Sorry. That would make way more work for the packagers, wouldn't really solve the issues that we're trying to discuss here, and would introduce other issues (like what about hybrid 32/64 installs?), so it's not really an option in this conversation. If you want to try to convince John to do that, I think it should go in a separate thread, as this one is about allowing users to choose 32-bit only or 64-bit only while installing the apps that we distribute currently as 32-bit/64-bit hybrids.
~3D1T0R
Hybrid installers are the worst in my opinion.
You download large file which in most of the cases will work only in one configuration.
Moreover, you lose the ability to run both side by side.
Regarding packagers, things should be automated to the level that doing twice of the same is zero work.
It is the same installers hence the same configuration is to be done.
You basically run the same thing twice (Hopefully scripted).
Solving the creation of an application overhead is a different issue and should be tackled orthogonaly.
By the way, it is the most important problem to tackle as it limits the extension of the suite with new applications.
Here's a PAF of an online installer for VLC Portable using the concepts that have been discussed in this thread.
Warning:
This maybe to advanced for some users to handle. Please read what you can expect with this version of VLC Portable further below. For anyone who dares to read the custom code for this online installer, look in the Source folder.
https://www.upload.ee/files/7573178/VLCPortable_x86_x64_Rev._5_online.pa...
About This PAF:
Associations=which can be set to a boolean value of true/false to turn on/off associations support.vlc.zip,vlc.7z, orvlc.exevlc64.zip,vlc64.7z, orvlc64.exe-xor/xswitch using the command line to the installer for extraction only.PortableApps.comInstaller.nsifile which I used to create this online installer. This can be found in the ..\Other\Source\Installer directory.If any of you guys find the urge to have a look at my custom code and decide to ask questions about what I did and/or why (not that any of you have or even tried), don't bother. I'm not explaining anything I've implemented in my PAFs anymore. When I just walk the walk instead of waste my talk, I find that progression seems to move forward much more smoothly on my end. This community is the only one which isn't impressed with my work and it's funny how this is the one community forum I try to hard for too.
Good luck trying to make sense of the advanced code in this version of VLC Portable.
daemon.devin
It is possible to make a post without insulting or belittling someone else.
Sometimes, the impossible can become possible, if you're awesome!