SvarDOS community forum

Hi Mateusz, what about RAM requirements for packages? For example, Blocek docs speak about 16 MB. hwreq could contain one of these: 640kb, 1mb, 2mb, 4mb, ... Some software also might be unable to use without a mouse. So I would add "mouse" to the spec. Or it could require a VESA-compatible graphics card, not just svga. (Blocek again) What about software only running on 80286 and *below*, because of timing issues? (I think about games here.) I could wish to express this with "hwreq: 8086 186 286", but pkgfmt.ama doesn't say anything about having more than one CPU family in hwreq. Cheers, Robert

Hi, I wanted this system as simple as possible, functional but without putting (too much) burden on packagers. So indeed, it is limited in a number of ways. The memory subject is rapidly becoming complex because what a program really needs is "available" memory, not "total" memory. And then, do we expect packagers to figure out that whether a program needs 180K or 250K? Might not sound like a huge difference, but it does make a difference for owners of a 8086 PC with only 256K of RAM. Also, some programs may want XMS, but others would expect EMS. Yet others will automatically support XMS or EMS, but do require one of the two. With so many options and scenarios, I felt it would be counterproductive to include (necessarily complex) RAM information in hwreq, since it would make it much harder for packagers to provide exact hwreq data... Adding a "mouse" requirement seems reasonable and easy. It just needs to be somehow made clear that a "mouse" hwreq is meant to be used only for programs that really cannot work without a mouse at all, and not programs that have mouse support. While SVGA is not the same as VESA, for practical purposes it is mostly a synonim, right? And for the few early SVGA cards that had no VESA BIOS, there is the UNIVBE TSR so it's only a matter of software configuration. It becomes more complicated if we want to differentiate between VESA versions. Some applications might be good with VESA 1.0 support, while other (3D games, mostly) could require VBE 3.x. But again - isn't this becoming too complex? I think that the hw filtering does not need to be 100% accurate, but it is important that it does not filter out packages (ie. it is better to provide a list with a few non-working packages rather than risking filtering out packages that are actually compatible with the hardware). The CPU level is currently expressed as a "minimum". Meaning that filtering 486-compatible software will list all packages tagged for 8086/80186/80286/80386/80486. I do not think that it is sane to expect hwreqs to contain a full list of all CPUs the package is compatible with, as this will increase the likelihood of human errors, while providing very little added value. Yes, some games might not run on a Pentium because of the runtime 200 error, but there are workarounds for this like "slow'mo", "fdapm speed", TPPATCH and others so a Pentium PC could still run them one way or another. It is the same situation with video requirements: When selecting "VGA", all packages having a hwreq with "MDA", "CGA", "EGA" will also be displayed. It is simplified, but works well for the vast majority of cases (and it is not possible to have a list of packages that will run on MDA but not on anything else). We can imagine lots of situations and odd configurations/requirements, but we need to draw a line somewhere so the system stays generally useful, easy to maintain and easy to understand. pkgnet is still not supporting/checking hwreq data btw, it is something I have to get to eventually. I think it will be done through a configuration file (C:\SVARDOS\CFG\PKGNET.CFG) where the user will have to select the CPU/graphic of the machine. And maybe at the same occasion the repo url could be made configurable. And maybe the repo IP, too, so pkgnet could use a tinier watt32 library with DNS and UDP support stripped away. Mateusz

> I wanted this system as simple as possible, functional but without putting (too much) burden on packagers. So indeed, it is limited in a number of ways.

Sure.

> The memory subject is rapidly becoming complex because what a program really needs is "available" memory, not "total" memory.

Total. As a rough estimate. If hwreq says 4MB is the minimum, I don't need to try this package on my 2MB system. No matter this memory is XMS or EMS.

> Might not sound like a huge difference, but it does make a difference for owners of a 8086 PC with only 256K of RAM.

Indeed.

> Also, some programs may want XMS, but others would expect EMS.

Which should be no problem with a 386+ CPU. One just needs to adjust CONFIG.SYS.

> With so many options and scenarios, I felt it would be counterproductive to include (necessarily complex) RAM information in hwreq, since it would make it much harder for packagers to provide exact hwreq data...

see at the bottom

> Adding a "mouse" requirement seems reasonable and easy. It just needs to be somehow made clear that a "mouse" hwreq is meant to be used only for programs that really cannot work without a mouse at all, and not programs that have mouse support.

+1

> While SVGA is not the same as VESA, for practical purposes it is mostly a synonim, right?

Mostly, yes.

> And for the few early SVGA cards that had no VESA BIOS, there is the UNIVBE TSR so it's only a matter of software configuration.

Yes, UNIVBE exists, but IIRC it was a commercial software, so it requires a license.

> It becomes more complicated if we want to differentiate between VESA versions.

It's not complicated, only more complex. It's no problem to add, e. g., "vbe10", "vbe12", "vbe20", "vbe30", and "vbe_but_i_dont_know_which_version_exactly". ;-)

> I think that the hw filtering does not need to be 100% accurate, but it is important that it does not filter out packages (ie. it is better to provide a list with a few non-working packages rather than risking filtering out packages that are actually compatible with the hardware).

ACK

> I do not think that it is sane to expect hwreqs to contain a full list of all CPUs the package is compatible with, as this will increase the likelihood of human errors, while providing very little added value.

ACK

> Yes, some games might not run on a Pentium because of the runtime 200 error, but there are workarounds for this like "slow'mo", "fdapm speed", TPPATCH and others so a Pentium PC could still run them one way or another.

I know about these solutions, but is some rare software, where this still doesn't help. I don't remember the name, but I think, it these were all games. Maybe a handful.

> We can imagine lots of situations and odd configurations/requirements, but we need to draw a line somewhere so the system stays generally useful, easy to maintain and easy to understand.

ACK

> pkgnet is still not supporting/checking hwreq data btw, it is something I have to get to eventually. I think it will be done through a configuration file (C:\SVARDOS\CFG\PKGNET.CFG) where the user will have to select the CPU/graphic of the machine.

And this configuration file could also be read/written to by the SvarDOS SETUP.EXE or SDCPL.EXE (SvarDOS Control Panel).

> And maybe at the same occasion the repo url could be made configurable. And maybe the repo IP, too, so pkgnet could use a tinier watt32 library with DNS and UDP support stripped away.

Yes, please! :-) And maybe we could increase buffers dynamically for later machines in order to make downloads faster. IIRC, we had some conversation about this around two years ago. Last, but not least, back to "would make it much harder for packagers" and "without putting (too much) burden on packagers": 1) Do we need to have the hwreq data *inside* a package? I don't think so. It could also be a separate file in the repo. 2) That would allow to distribute the work of providing proper hwreqs to any SvarDOS user. Yes, it would require to created a more advanced web interface (probably with user registration), where a user can select on what hardware configuration a specific package worked for him/her. Of course, this is also not free from errors, but if five users say "it worked on my 2MB 286 with EGA", this should be accurate enough. If this will require to "hire" a part-time PHP programmer, then we (or I) will look for one.

> Total. As a rough estimate. If hwreq says 4MB is the minimum, I don't need to try this package on my 2MB system. No matter this memory is XMS or EMS.

I see, a similar approach to what could be seen during the 90s in various shareware magazines that reviewed software - like "Great adventure game with joyfully animated graphics and challenging elements of logic, 486 / 8M RAM / 65 MB HDD". Maybe that's not a bad approach. It has the advantage of being simple to understand. Maybe instead of tokens it could be a numerical value (in KiBs), like "RAM=512", "RAM=4096" etc, so it would be easier to process and compare such information.

> Yes, UNIVBE exists, but IIRC it was a commercial software, so it requires a license.

Isn't it freeware nowadays? The archive from SciTech mentions a "DOS ONLY Free Version": http://web.archive.org/web/20080120054601/http://www.scitechsoft.com/ftp/sdd/ I got the link from this vogons thread (where a bunch of other very cool VESA utilities are mentioned): https://www.vogons.org/viewtopic.php?t=15190

> maybe we could increase buffers dynamically for later machines in order to make downloads faster.

Either dynamically, or simply configurable through the same PKGNET.CFG file.

> Do we need to have the hwreq data *inside* a package? I don't think so. It could also be a separate file in the repo.

Could be. The advantage of having it in the package is that the package is "self contained" and when developers produce SVP packages themselves, they have control over the advertised hwreq. And it does not take much space, most LSMs fit easily in a single sector.

> it would require to created a more advanced web interface (probably with user registration), where a user can select on what hardware configuration a specific package worked for him/her.

I think this approach would work if we had lots of (motivated) users. For the time being, when it comes to "active" users (that are motivated enough to write something on the forum or on the bugz tracker) we have something like statistically 3 and a half user. Not much for crowdsourcing "big data" solutions. But let's assume we could/would have more users: I do not think there is any need to ask them to do such work because the server-side pkgnet would already have all the required information. It would know the list of all hardware configurations that ask for packages (because of the hw declaration in PKGNET.CFG) and it would also know who has what list of packages installed (because of PKGNET CHECKUP). Mapping both data would lead to a statistical view of "what is the minimum hw configuration that this package has been seen on". I think something like that was actually suggested on bugz (or was it OSDN? not sure) some time ago. I think it is too early for investing time into such things (because of the limited user base), but perhaps a first step could be that PKGNET collects some rough stats about downloaded updates. Just enough to provide us with an approximate clue of how many people use SvarDOS. This could even be made public, since the information would contain nothing personal. The only challenge that I see is to distinguish a single PC asking for updates two times from two PCs asking for updates one time each. Ie. some identifier would have to be computed by PKGNET. Maybe the MAC address would be good enough... although with VMs nowadays I imagine the same MAC address might be used by many VMs...

> If this will require to "hire" a part-time PHP programmer, then we (or I) will look for one.

Independently of this subject, patches (PHP, C, others) are always welcome. :) Mateusz

> I see, a similar approach to what could be seen during the 90s in various shareware magazines that reviewed software - like "Great adventure game with joyfully animated graphics and challenging elements of logic, 486 / 8M RAM / 65 MB HDD".

Exactly. Similar was printed on the outside of big-box games. (I still have some at the basement, but I never play. :-/)

> Maybe instead of tokens it could be a numerical value (in KiBs), like "RAM=512", "RAM=4096" etc, so it would be easier to process and compare such information.

I'm undecided about the format. So feel free.

> Isn't it [= UNIVBE] freeware nowadays?

I will have look ... You are right. :-) Also found those files in my DOS archive.

> I got the link from this vogons thread (where a bunch of other very cool VESA utilities are mentioned):

> https://www.vogons.org/viewtopic.php?t=15190

Most of these are also in my DOS archive since many years. :-) Maybe I should catalogue my archive some day, because original 8.3 filenames aren't very descriptive.

> Either dynamically, or simply configurable through the same PKGNET.CFG file.

Okay.

> The advantage of having it in the package is that the package is "self contained" and when developers produce SVP packages themselves, they have control over the advertised hwreq. And it does not take much space, most LSMs fit easily in a single sector.

Makes sense for developers, yes. But for all other packages (the majority) hwreq could be a separate file (or a database entry), because you don't need hwreq data on your SvarDOS machine (permanently).

> Mapping both data would lead to a statistical view of "what is the minimum hw configuration that this package has been seen on".

Nice idea.

> I think something like that was actually suggested on bugz (or was it OSDN? not sure) some time ago.

I also don't remember.

> I think it is too early for investing time into such things (because of the limited user base)

I see.

> Just enough to provide us with an approximate clue of how many people use SvarDOS.

Could be interesting indeed.

> This could even be made public, since the information would contain nothing personal.

As long as you don't use this data for profiling, it would be okay. But the more packages of different types the SvarDOS repo provides, the more accurate this data could be used for profiling. Yes, this is theory.

> some identifier would have to be computed by PKGNET

Yes, you need a machine ID or UUID (https://www.uuidtools.com/what-is-uuid)

> Independently of this subject, patches (PHP, C, others) are always welcome. :)

Good you say it. :-D I hope, my small change to PKG output is okay for you. It makes the number of (unzip) errors easier to spot. We talked about this 1.5 years ago on the SvarDOS mailing list, I think.

> Yes, you need a machine ID or UUID (https://www.uuidtools.com/what-is-uuid)

UUID is a modern, complicated concept. But yes, that's the idea. HOWEVER: UUID is assumed to be unique because it embeds the MAC address of the computer. These are mostly unique for physical NICs (with some odd exceptions like Chinese manufacturers releasing batches of cards with the same NIC - I happen to have been confronted to this issue in my work some 15+ years ago...) but most importantly - this no longer holds true for virtual machines, which generates fake MACs all the time. Not sure this is a blocking issue for us given the tiny user base, just pointing it out. And I do not have any better idea anyway, so the identifier would probably end up being a combination of MAC + pkgnet hw string + maybe the serial volume of the C: disk.

> I hope, my small change to PKG output is okay for you.

Yes, I've seen it yesterday. It makes no difference at all to me, so if it makes you happy then I'm happy as well. :) Mateusz

> UUID is a modern, complicated concept. But yes, that's the idea. HOWEVER: UUID is assumed to be unique because it embeds the MAC address of the computer.

Looks like you didn't take the time to read about the different UUID versions: https://www.uuidtools.com/uuid-versions-explained Not all embed the MAC address.