@JonathonWyble We were contending with an already quite large table and this was a way to eliminate a column. It's an ongoing process and part of it may (may) involve bulk-renaming downloads to shorten their names, which may make that column space available again.
In the grand tradition of retrocomputing, we are struggling to figure out how to make UI that condenses tons of information into a small space without being confusing or overwhelming to anyone.
When dealing with Windows 3.1 and Windows 9x/NT software the 16-bit 32-bit distinction is a huge deal. 386 and 8086 is a little too specific, the majority of 16-bit windows programs required at least a 286 so that would be misleading.
I've already experimented like crazy with shortening download names. In general this just causes more confusion if things don't match.
For the most part, the only shorting that has helped has been removing the repeated "Microsoft" from in front of the busier Microsoft products. (however, it needs to be in the 7z file name for sorting purposes). And even then, it is more of an art figuring out where this works well or not. Except for some of the Windows pages, that is not a big deal.
That's a fair point although the Windows pages (and other OSes) are kind of where we keep coming back to - the multiplatform single downloads are mostly OSes for instance, I suspect it's precious few applications that come in six different flavors on the same disc but Windows NT sure does. You definitely have a point as far as getting too focused on those.
To ask it point-blank - what do you think we should use? Are x86-16 and x86-32 reasonable to you, or something else, or is what we have right now the best it's going to get?
Also, what if we were tracking in terms of specific CPU features? Soon the platform options should be data-driven, and then we could populate all kinds of flags, like "286 supported", "286 required", and similar for 386, pentium, other platforms etc. and just add new ones as needed.
It'll be technically possible soon, the question is whether that's worth it, or if it's enough to solely track 16/32 and leave everything else to the user to discover.
To ask it point-blank - what do you think we should use? Are x86-16 and x86-32 reasonable to you, or something else, or is what we have right now the best it's going to get?
Yes, I'd just leave that as is. Keep in mind that I am the one who has written/re-written the descriptions and filled in these fields for almost all of the products on this site.
To re-iterate in a nutshell, x86(16-bit) includes all DOS programs, and all native Windows 3.1 or earlier programs. x86-32 includes all native Windows 95/NT programs as well as Windows 3.1+Win32S programs.
Also, what if we were tracking in terms of specific CPU features? Soon the platform options should be data-driven, and then we could populate all kinds of flags, like "286 supported", "286 required", and similar for 386, pentium, other platforms etc. and just add new ones as needed.
It'll be technically possible soon, the question is whether that's worth it, or if it's enough to solely track 16/32 and leave everything else to the user to discover.
Data driven? What the hell are you talking about?
We already have a CPU field for the release that gives more information (sometimes specific platform)
But with many software products the real requirements are "read the manual, it's complicated" or "frick if I know, we don't have the manual". In many cases the requirements are conditional depending on the configuration installed. In many cases a program may run on a CPU that was not officially supported (some obscure piece may fail). In others it might run if some tweeks are made. A lot of early software specifically listed manufacturer's computer models, rather than "cpu".
I usually wind up leaving the release minimum CPU and RAM files blank because I simply don't know. A Windows 3.1 program that runs in my Windows 3.1 386 emulation might or might not work on a 286 but I don't have time to test, and there is no manual. Some software may fail on a faster CPU due to speed or other odd incompatibilities, and even a manual would not tell you that.
So all of this, if I have it, goes in to the release description.
"This product requires a Macintosh 128k or 512k, it will not run on a Mac Plus or later"
"This product release includes a Macintosh M68k binary for a Macintosh II or later with at least System 6, a Windows 3.1 binary that requires a 286 or later, and an MS-DOS version compatible with an 8088".
Data driven in this context means moving a lot of the information like architecture into tables in the DB. Right now it's basically some constant values on SET/ENUM type columns, plus some constant value to friendly name translation. This makes extending the set of architectures (or media types, tags, etc.) a bit of an ordeal, so making it based on stuff in the DB makes it easier to modify without having to modify the schema. (That, and properly extending them all to be a many to many relation, instead of 1-to-n or worse, the very non-relational set type.)
(It also makes deploying the CMS more of a blank slate appropriate for deploying from scratch.)
Oh, and we're also in the long term looking to clean up a lot of the irregularities of the schema used, mostly to make it easier for mechanical filtering.
Comments
The icon has alt text, so it'll show on hover.
@JonathonWyble We were contending with an already quite large table and this was a way to eliminate a column. It's an ongoing process and part of it may (may) involve bulk-renaming downloads to shorten their names, which may make that column space available again.
In the grand tradition of retrocomputing, we are struggling to figure out how to make UI that condenses tons of information into a small space without being confusing or overwhelming to anyone.
When dealing with Windows 3.1 and Windows 9x/NT software the 16-bit 32-bit distinction is a huge deal. 386 and 8086 is a little too specific, the majority of 16-bit windows programs required at least a 286 so that would be misleading.
I've already experimented like crazy with shortening download names. In general this just causes more confusion if things don't match.
For the most part, the only shorting that has helped has been removing the repeated "Microsoft" from in front of the busier Microsoft products. (however, it needs to be in the 7z file name for sorting purposes). And even then, it is more of an art figuring out where this works well or not. Except for some of the Windows pages, that is not a big deal.
That's a fair point although the Windows pages (and other OSes) are kind of where we keep coming back to - the multiplatform single downloads are mostly OSes for instance, I suspect it's precious few applications that come in six different flavors on the same disc but Windows NT sure does. You definitely have a point as far as getting too focused on those.
To ask it point-blank - what do you think we should use? Are x86-16 and x86-32 reasonable to you, or something else, or is what we have right now the best it's going to get?
Also, what if we were tracking in terms of specific CPU features? Soon the platform options should be data-driven, and then we could populate all kinds of flags, like "286 supported", "286 required", and similar for 386, pentium, other platforms etc. and just add new ones as needed.
It'll be technically possible soon, the question is whether that's worth it, or if it's enough to solely track 16/32 and leave everything else to the user to discover.
By "alt", did you mean "title"? Then yes, I noticed that, too. Never mind my suggestion on retaining the file type column.
Yes, I'd just leave that as is. Keep in mind that I am the one who has written/re-written the descriptions and filled in these fields for almost all of the products on this site.
To re-iterate in a nutshell, x86(16-bit) includes all DOS programs, and all native Windows 3.1 or earlier programs. x86-32 includes all native Windows 95/NT programs as well as Windows 3.1+Win32S programs.
Data driven? What the hell are you talking about?
We already have a CPU field for the release that gives more information (sometimes specific platform)
But with many software products the real requirements are "read the manual, it's complicated" or "frick if I know, we don't have the manual". In many cases the requirements are conditional depending on the configuration installed. In many cases a program may run on a CPU that was not officially supported (some obscure piece may fail). In others it might run if some tweeks are made. A lot of early software specifically listed manufacturer's computer models, rather than "cpu".
I usually wind up leaving the release minimum CPU and RAM files blank because I simply don't know. A Windows 3.1 program that runs in my Windows 3.1 386 emulation might or might not work on a 286 but I don't have time to test, and there is no manual. Some software may fail on a faster CPU due to speed or other odd incompatibilities, and even a manual would not tell you that.
So all of this, if I have it, goes in to the release description.
"This product requires a Macintosh 128k or 512k, it will not run on a Mac Plus or later"
"This product release includes a Macintosh M68k binary for a Macintosh II or later with at least System 6, a Windows 3.1 binary that requires a 286 or later, and an MS-DOS version compatible with an 8088".
Stuff like that. It's not that simple.
Data driven in this context means moving a lot of the information like architecture into tables in the DB. Right now it's basically some constant values on SET/ENUM type columns, plus some constant value to friendly name translation. This makes extending the set of architectures (or media types, tags, etc.) a bit of an ordeal, so making it based on stuff in the DB makes it easier to modify without having to modify the schema. (That, and properly extending them all to be a many to many relation, instead of 1-to-n or worse, the very non-relational set type.)
(It also makes deploying the CMS more of a blank slate appropriate for deploying from scratch.)
Oh, and we're also in the long term looking to clean up a lot of the irregularities of the schema used, mostly to make it easier for mechanical filtering.