What is going on with Limewire? More and more features -- worse and worse performance. I get "out of memory" errors quite regularly on my Windows XP machine -- with a GIGABYTE OF RAM! No way should it need close to that much, let alone *more*. Simply leaving it on overnight suffices to ensure at least 3 of the buggers waiting for me in the morning, like christmas presents wrapped by the devil, and probably also a totally dead, hung UI. It was bad in 3.8.5, got a bit better up until 3.8.10 was almost tolerable, and then 4.0. 4.0 apparently demands as much ram as high end CAD and video editing tools, since it reports out of memory on a 1GB machine regularly, hangs a lot, and has every other error imaginable save outright closing itself down. Also, what's with it refusing to resume old downloads more often than not? I thought keeping your downloads across sessions was supposed to have been added as a feature way back in 2.something. I'm still waiting for it. It won't run for more than maybe an hour without becoming slow and unstable. Long freezes occur during which it drops half its connections, the UI won't respond, and task manager shows it gobbling up CPU, hardly touching the NIC, and spawning dozens of new threads, not to mention consuming 100MB+ of RAM (but nowhere near 1GB). These hangs begin to occur if it's left running for very long at all, and become very long and frequent and cause transfer failures and poor search results if it's left to run for more than maybe two hours. If it's left to run overnight, you can forget about it -- it's either hung, or at least in a really wacky and unstable and not properly functional state. (I personally love it when the tables start flickering wildly like a Commodore 64 game during a brownout in the days of yore around 1985 or so, and the "auto-sort table" setting is ignored even if it's checked.) Honestly, there's no reason it should need that much RAM, and still complain there's not enough memory on a 1GB machine, hang and misbehave often, become unstable just from leaving it running with a fixed workload (the same number of shared files, upload slots, and queue slots). It's obviously got a severe object leak inside, one that got abruptly much much worse with 4.0's creeping features adding yet more object churn.

Relevant system specs: Windows XP Home SP1 with all critical updates up-to-date; up to date network, video drivers; cable Internet connection; correct firewall configuration (I can download and upload successfully -- for about one hour, and then Limewire becomes virtually unusable, that is); 1.5GHz Athlon XP 1800+, 1GB RAM, and 3MB/s bandwidth up and down (i.e., may as well have a dual T1 running into this thing, except they'd cost more); and several GB of free disk space. Throw in swap, and there's effectively 1.6GB RAM available, and the system hardly ever gets above the high 700s as indicated by task manager, which eliminates swapping as the cause of the slowdowns, hangs, and errors. Sharing about 10,000 files -- too bad nobody can get the larger ones, since Limewire will have to be shut down long before the transfer completes even at cable speeds, so this isn't a freeloader complaining here. Current version: Limewire (free) 4.0.4 and wishing I had stuck with 3.8.10 which actually worked for four hours straight once without being restarted and once or twice actually remembered my downloads across sessions.

This user isn't buying Pro anytime soon, and isn't buying it ever unless there's an update Real Soon Now that addresses the worst of these performance problems. No filesharing application should need >1GB RAM to function without memory allocation errors. I'm astounded that the minimum system requirements listed include "64MB RAM" when my own machine, with 16 times that much, clearly does not meet Limewire's minimum system requirements -- and Limewire makes sure to remind me hourly of this fact!

If you want people, the vast majority of whom are running Windows XP, to leave it on overnight, it has to actually work when left running for that long, and not lose peoples' data regularly if it's not restarted very frequently. As near as I can tell the rules for keeping the dreaded internal errors and "could not resume old downloads" at bay, not to mention slowups and hangs of the UI, are as follows: Don't queue many downloads at once -- 100 is enough to give it problems right away. Don't let it run for very long. Only perform 1 search per session -- forget about five search tabs at once, though that was quite fine under 3.8.10. Close it the minute it gets slow, even if it means interrupting an incomplete download. Don't share thousands of files. In short, it's better to be a freeloader that hops on to do a quick search and grab a few files than to try to dedicatedly share a load of stuff. This isn't the message I think you want to be sending. Also, bad experiences with hanging, crashing, data loss, and the like with the free version does not make for a very good advertisement for the pro version.


On a side note: why does it seem to be more difficult to get small files than large ones? It's easier to get a 100K chunk of a 100M file than to get a 100K file, it seems -- if I queue a bunch of multi-meg MP3s I'll see a ton of them downloading, often from 5 or 6 hosts apiece, and few to no need more sources or partial downloads. If I queue a bunch of itty bitty jpegs, I'll get two, and the rest will fail, except some 20K file will die at 98% complete. What the hell? How can it fail there? The packet used to send the stupid busy signal could have been used to send the other 2% of the damn file, it's that small. I get the feeling there's an economy of scale that cuts both ways, with overhead dominating actual file data for files under 1M. People do share things other than mp3s you know. Photo albums, for instance. I suggest maybe some small file optimizations are needed in the system as a whole. For instance, when many small files are requested from a host that has them all, they could be sent as one big lump -- tar and untar them on the fly, perhaps? Small files do often occur in batches of related files on a single host. Or some sort of chain-downloading, or just not dividing files smaller than some size into chunks at all -- what's the max size of a network packet? 64K? So break small files into chunks 32K in size, sending files up to 32K in size in one packet. An express line would be useful too, limited to small files and maybe to high-speed (DSL or better) uploaders. Seeing (or being!) a cable user stuck in line behind five slow modem users all requesting multi-meg files blows chunks -- and wastes my upload bandwidth.

Of course, one pain in the network is all the Shareaza (and others, but mostly Shareaza) hosts configured to 0.000001KB/s upload bandwidth by clueless people in the mistaken belief that this helps their download speeds -- on most setups, you get separate bandwidth pools for up and downstream flow, and on 56K dialup, your connections to ultrapeers are probably already reducing your download speed to 28K. Besides, dialup speeds suck too much to suck noticeably more because you actually let people get files from you. Sharing files at 0.00001KB/s is just a way of being a freeloader without showing up as a freeloader on clients that detect them purely by counting files.

And can we please have a "no to all" button on the download overwrite prompt? I'm sick of clicking the plain "no" button 50-odd times when trying to suck up a whole category of search results, such as a big bunch of jpegs, in order to speed their propagation through the network -- having more high-speed sources for files helps everyone, so making it a pain to be such a source does not. Also, I thought I saw a new option in 4.0.2 (though it seems to be gone in 4.0.4) to ban anyone that downloads more than some number (I think the default was 5) of files from you! Needless to say I turned this off -- I want high speed hosts to be able to snarf up large numbers of file, then they become much more available over the network. Preferencing of high speed uploaders makes sense though, especially for a file your host knows of few high speed sources for via the mesh. I hear the term "greedy client" a fair bit lately -- IMO the only "greedy client" is a client that isn't sharing files. A high speed client with large numbers of files should be preferenced and never banned, as uploading a file to such a client aids its propagation through the network greatly. Besides, I don't like the implications such a feature has for rare content: if there are six rare files only to be found on one host, and that host only ever allows a given person to get five files, then they can NEVER HAVE all six rare files, unless someone else gets one and then shares it. Or they cheat and use a free AOL disk to get a temporary account with a different IP address. Speaking of which, banning specific hosts is nearly impossible anyway, since nearly everyone has a dynamic IP address. (The downside is that banning specific *files* -- mutilated files plastered with ads, for instance -- is impossible too. Even if the host polluting us with such files is a dot-com with a fixed IP, while consciencous sharers like me that get such files in the process of trying to build a comprehensive library of one type of content review all new files before sharing them and delete such tripe, plenty of people will have left their download directory shared by default and will also proffer these crooked files. I think maybe there should be a gnutella layer for voting on files -- files get a reputation and clients let you preview new files before sharing them, and delete instead. If the file sucks due to being mutilated with ads, damaged, etc. you can vote it down by deleting it from this preview window, and the information propagates through the mesh and is stored by clients as metadata. Search results indicate the file's quality with a star rating, as well as indicating the file's availability somehow and its speed somehow. The show search results filter options would include filtering by speed, availability, and reputation. If most people who downloaded the file deleted it, it's probably damaged, ad-spammed, or the filename misrepresents the content in some way.

By the way, what doofus registered the name "Unregistered"?

That's 100+ queued, I only set it to allow 20 download connections at once.

a good read--lots to think about. Thanks.

re the crashing---FWIW, I reorganized my shares (4.5 GB; ~1400 files), and then started having start-up problems. Bit the bullet, trashed the fileurns.cache and .bak, waited the 40 mins for them to rehash (thought maybe it would be faster than the 1GB/10 min figure it used to be). The CPU stayed ~35-40 % which is MUCH better than before, and everythings been much quicker since. No data loss, gui slowdowns, etc. Can't say I've seen any error messages though, and it ran for 50 hours this weekend (OSX). So--looks like a new fileurns.cache is good here.

re the 100+ downloads, I can't offer anything similar. Did try 50 plus (small) at a time last week--I guess habits develop because it seemed abusive--but couldn't see any problems other than firewalled (?) hosts that only let one or two at a time through. btw--since the search results now show already downloaded files, I'd forgotten about the old request for the "remember" checkbox.

Sure like your idea of making a block of lots of small files equivalent to a single large file as far assigning upload slots, and preferencing those who request unique files. What about allowing "folder" downloads? The Library can show paths . . . and looks like the Library is on the agenda for the next batch of attention. Yeah! Directory uploads! Should cut the messaging chatter considerably too!

I don't buy your "no Pro" argument though. Sounds more like it should be "Get Pro" so there's more push to get the program developed and fix those bugs--many of which remind me of when Java and OSX were (are) learning to play nicely together. Aren't all of you on XP due for a Java update soon--1.5, isn't it?

cheers

May try that.

The faster you get files, the faster you share them -- I don't see how that can be abusive. As for the new icons showing already-downloaded files, it would help if only the icons were accurate. Unfortunately, they aren't: doing a search often produces results listings with stars by items you already have, and even occasionally a checked paper by something you don't.

An incentive to fix bugs is to make people thing "This thing is great! I'll chip in and get pro." Give them your money before they're fixed, and the incentive disappears. I thought software users had learned that a long time ago, from Microsoft -- once they have your money they don't give two puffs any more, save that more bugs makes it more likely you'll pay to upgrade...

As long as there are serious bugs I keep waiting one more version, one more version to see fixed, I want to keep on the "upgrading is free" side of the divide thank you very much. I might consider paying for a genuinely stable product. Current versions don't approach that by a country mile, especially the 4.0 series...

As for a new version of Java, I hadn't heard. 1.5 sounds like an unstable version though -- wouldn't it likely make things worse? Might be better waiting for 1.6. Also, given that Limewire's performance took a steep nosedive going from late 3.8 to 4.0.2, it seems that major version jumps and the accompanying new feeping creatures tend to be accompanied by sharp drops in performance, only made up gradually over succeeding minor version increments (e.g. the improvement from 3.8.5 to 3.8.10) -- so going from Java 1.4.2 to 1.5.0 will probably mean going from a fairly well tuned VM to one that runs badly. Running an app with performance problems inside a VM with performance problems would compound problems massively.

And none of this addresses the disturbing fact that it regularly complains of being out of memory when run on a 1GB machine...

Uh ... where exactly is the fileurns.cache? It's not under the Limewire directory at all, as far as I can tell -- neither under 4.0.4, nor incomplete, nor lib, nor shared. Maybe it has a different name under Winblows?

Bah...Agent Ransack eventually found it in a hidden directory in a part of the filesystem ten thousand miles away from Limewire itself. It seems to want to save some settings on a per-user basis on multiuser OSes. The location in a hidden directory predictably made the built in Windows search fail to find it. Even with show hidden files etc. turned on in it, in Explorer, and everywhere else I've seen such a setting...

Well, it's using as much ram as it ever did, around 120M, but it's not complaining or slowing down quite as much. What happens to the index file that causes this (or at least, worsens it?) Why isn't it listed as a Known Problem with a Known Workaround in the appropriate section of the user's guide on the Web site? Is there a way to avoid the index file being damaged in this way? Does upgrading cause it, maybe due to a drift in the format of this file which gets markedly worse when it's a major version number increase (e.g. 3.x to 4.0)? If so, why isn't it converted when an upgrade is run for the first time, or at least rebuilt? (ICQ does this with its database files sometimes when you upgrade. Otherwise it's no example to follow: slow, bloated, somewhat buggy, though not as bad as MSN for taking matters into its own hands and deciding you wanted it to disconnect when you told it no such thing. And that silly mouse buttons dialog! Why not just make either mouse button bring up the menu, or make clicking just select a contact, double clicking launch a message window, and right clicking bring up the menu? The latter would fit standard windows UI behavior, and although currently double clicking is supposed to open a message window, half the time it opens the menu instead and sometimes it seems to simply do nothing, or the app hangs...)

Bah. I just found out that Limewire got 32% of a file and then choked.

The file is 12K (yes, you read that right, 12K) long.

Why the foo didn't the remote host send the whole damn thing in one chunk? The maximum size of a network packet is 64K, easily big enough to hold the whole thing plus overhead, for god's sake. I can think of no rational reason for this, save someone wasn't thinking of anything but mp3s when they optimized this sucker. Except I am unsure that qualifies as a rational reason.

On a side note, I see a lot of downloads broken off at suspiciously round numbers. 32 and 33 and 67 and 25 and 50 and 75%, for instance. I can't see why random network outages or people just happening to go offline would disporportionately often happen when a transfer's fraction completed could be expressed in small integers. But human beings have such preferences. Is there a client out there that deliberately serves a fixed, small integer fraction of a file (e.g. a third or a quarter) and then boots a host to the end of the queue, and then forgets them so they end up with "Blah blah ... 32% complete ... Awaiting Sources"? If so, can it be detected and banned with some undocumented config option? (Filtering by vendor/version regex matching seems to be a curiously lacking but desirable feature, given that all client programs are emphatically NOT created equal!) Especially as it obviously cluelessly applies this policy to files large and small, and even small enough that the whole remainder of the file could have been sent in place of the damned busy signal used to terminate the download!

If the intent is to let people requesting small files get them quickly without being stuck interminably behind several multi-meg uploaders, isn't an express lane a superior solution? Especially as interrupting a transfer, in my experience, carries a measurable risk of damaging the file not incurred if it's continued to completion. Also, IMO when an upload fails, for some time the uploader should hold the slot open for resuming the same file. There should be a good faith effort to follow through and complete the transfer "through rain or snow or sleet or gloom of night" -- or routing glitches or one host's dynamic IP changing or one's dialup connection dying and needing redialing. As it stands, it's common for a download to fail partway through and uncommon to ever resume it successfully, at least not without extensive searching and requerying. And limewire makes you restart the client to requery a file again if it doesn't find it the first time...

ARGH.

The internal errors, slowdowns, hangs, etc. are back as bad as ever after letting it run a couple hours and selecting a hundred or so files to queue for downloading eventually. What is wrong with this software? How can it possibly be out of memory when Windows Task Manager shows [/b]less than half[b] the total available virtual memory in use? If it's not, why say that it is and then get unstable? Who designed this thing anyway? :P

Actually, given the stability and slowdown problems, which lead to dropped connections with network events aren't serviced fast enough because it's gone creating dozens of threads that take CPU priority over the event handling thread for some insane reason, maybe a useful idea would be to have reserve connections. These would be reserved spaces on ultrapeers, but without anything much actually happening in the way of traffic; they wouldn't be used to route searches for instance. Like the upload queues, they'd be the next in line, but leaves would have them too -- one at least, and maybe a full four, ready to go live the moment an existing connection dropped. Thing is I'm sick of seeing at least one red bar most of the time on my connection meter. It's not just that it drops connections frequently; it's also slow to reestablish them. (It was slow in 3.8.10; it was really slow in 4.0.2 with locale preferencing, until I turned that off; now it's merely slow again.) If it held one in reserve to switch in as active at a moment's notice it could recover nearly instantly from just one dropped connection. Unlike an active connection to an ultrapeer, a reserve connection would not need to consume much in the way of bandwidth or resources at either end prior to becoming active.

Basically, the idea is to do the work of finding a replacement connection for one that fails *before* it fails, rather than after, but sit on this information until there is at least one new connection needed and use it only then. A form of precomputing in order to optimize recovery from network hiccups.

I suppose that still wouldn't help with search results being poor if a connection or two bomb right after you start a search, which is all too common, leading me to suspect the existence of "fair weather friend" ultrapeers that are quite happy to route searches your way but drop you like a hot potato the minute you send off so much as 1 query yourself... Anything that supports uploading as somehow "better" than downloading hurts the network, since equal amounts of uploads and downloads is what will actually happen barring some kind of multicasting extension, and that means making it a pain to download reduces uploading in equal measure anyway.

And the f*cking thing jsut hung AGAIN. I switched to it after that last post and got nothing but a blank grey window. Minimizing and unminimizing didn't change anything; maximizing and unmaximizing either. Trying to reduce it to the tray by the close box had no effect whatsoever; Limewire simply ignored me, which is ABSOLUTELY NOT CORRECT BEHAVIOR FOR AN INTERACTIVE APPLICATION -- UNDER --ANY-- CIRCUMSTANCES WHATSOEVER!!!!! I am fed up. I want these bugs fixed. I expect a genuinely STABLE "stable branch" version on the website by next Wednesday evening or ****ing else!

I don't like having to regularly kill something via task manager. I don't like it losing my download list when I do. I don't like the way it brainlessly loses the list even though while riffling through its directories earlier I saw that it DOES save a ****** backup -- which either it doesn't use, or stupidly corrupts at the same time as the main copy instead of always leaving the backup file as the last known-good version. I don't like applications that gobble up RAM and then complain that a full gigabyte is still not enough for them, and I don't like anything that regularly hangs or loses data for whatever reason. There's no excuse for showstopper-magnitude problems like this outside the odd-numbered branch, for Christ's sake; no excuse at all. Nor for posting "minimum system requirements" of a few measly megs of memory (64, was it?) and a couple hundred MHz CPU when I regularly see it max out the CPU on a 1.5GHz Athlon and complain of low memory on a machine with sixteen! times! the minimum recommended memory. And I don't need anomalously heavy usage to experience these issues either; simply starting it with a blank download list and leaving it on overnight suffices to hang the 4.0 series on my machine. Which ought logically to be able to run ten instances concurrently without more than a little slowness with bandwidth, given that I never see it exceed around 120M actual memory usage or 1/3 the total bandwidth I have.

I don't know if it's because it's written in Java, or because the developers are clueless, or because it just doesn't play nice with Windows XP. The fact of the matter is it just plain does not work acceptably on a run of the mill middle-high end system with the commonest end-user OS, up to date on service packs and drivers, with a broadband connection, and sharing a reasonably large library of files. That's not tolerable. The speed and stability of 3.3.5 must be brought back or else the features have to start being scaled back as too expensive in terms of performance. That's the bottom line.

You have till next Wednesday, close of business. If I don't see a version on the site then that actually works on my (by no means low-end) machine, then it's the end of any chance I'll ever spend a dime on pro, and the start of a very high likelihood I'll report these issues rather more widely so as to facilitate informed consumer choice.

If there's any remainind doubt that these problems are occurring with nonexcessive or abnormal usage and a fairly beefy machine, the following just happened:

Started it up again -- predictably, it refused to resume old downloads. Sharing 10,681 files. Hash index recently rebuilt. I did a single search; after five minutes I switched back to Limewire and found 192 results (some duplicates, and most files I already have). Selected them all and hit download, then sorted through the overwrite dialogs hitting "no" to each. (This, rather than just sort by "quality" and select just the ones with stars, because I've found the paper-with-check often fails to appear for files I have and sometimes appears for files I don't. Until it works I'm stuck with this method for making groups of files complete.) About 3/4 of the way through the list, Limewire hung, and task manager showed greatly decreased network activity and over 100 threads. About five minutes later, the thread count dropped to around 50 and the UI became responsive again. At this point commit charge 798M/1622M, actually on the high side for usual; note that 1GB of the 1622 is *physical* ram so the system's about two more Limewire instances away from swapping, let alone running out of memory, based on its current process size of 103,664K (that's VM process size listed in Task Manager -- both virtual machine and virtual memory, so, the true size of the process excluding DLLs concurrently in use by other processes). Nonetheless, there's an out of memory error dialog displayed prominently in the Limewire UI, mocking me and my gigabyte of RAM. I dismiss it, and note that my connection quality is merely good -- one red bar. Within seconds, though, it becomes two and then three! Limewire has apparently taken it upon itself to close some connections without any input from me on the matter -- and it must be happening locally, since independent failures at three remote hosts (or routing three remote hosts) are very unlikely indeed. Astronomically so. Either my network connection is malfunctioning or Limewire is, and the network connection checks out fine since browsing to this "submit a post" page in Firefox gives no trouble or so much as a hint of delay. If www.gnutellaforums.com is reachable it's unlikely three specific independent hosts in geographically random locations (thanks to turning off locale preferencing!) all became unreachable within seconds of one another. Oh no, Limewire is surely to blame here, taking the initiative to trim bandwidth usage I suppose, while the task manager's network monitor shows a full 2/3 of my bandwidth available. (This is with normal activity; it recovered about when the bogus out of memory error appeared.) Shortly the connection quality recovers. In the download list: seven files. Miraculously, one of them actually ****ing downloads successfully in seconds, as I watch in astonishment.

Seven files, and up for about ten minutes, one search done which returned a typical number of results -- that's all it takes to get unacceptable crashes/misbehavior from Limewire on a 1.5GHz 1GB Athlon machine. The developers must test this on 4GB quad Xeon boxes or something if their test suites don't reveal problems like this prerelease. Nothing, however, excuses them from releasing into the stable branch code that must have had everyone betatesting 3.9.x pulling out their hair at the error messages, the frequent hangs and data loss... What were they THINKING?!

Addendum: it failed to find the other 6 files on requery, and it also failed to find more than about 800 additional MB to allocate on several further occasions, each announced with great fanfare with a huge, focus-stealing dialog box. (Exactly how big a chunk it requested each time is a mystery, but it has to have exceeded 800M for the system not to find it somewhere in the bowels of the 1600M virtual memory with only 700-odd in use.) I closed it down, and waited the interminable time it takes for the process to disappear from task manager (over 2 minutes this time; I clocked it, and sometimes it's over ten) before launching a new instance.

Predictable as cloudless skies in the weather forecast for Cairo: "Sorry, but Limewire was unable to resume your old downloads!" There's no excuse for the code to display that dialog even being in the source tree, let alone actually being executed. And for a list of only six files? How ****ing hard can it be to load six old downloads? Especially when I've seen older versions (3.3.5 comes to mind) able to load over 2000(!) without difficulty -- and that arguably *is* excessive.

This software sucks. Version 4 just plain doesn't work. It sort of goes through the motions of vaguely resembling something that's pretending to work while actually only being a cardboard cutout that does no work at all well -- a big, fat, lardy 100MB cardboard cutout that is. And it sure uses a lot of CPU doing nearly nothing except failing to present a UI, composing the latest out of memory error dialog of doom to present to me like a birthday gift from Satan (the clocks must all be wrong down there since it's not my birthday for some months yet, but since they can't ever see the ****ing sun or moon from there I can't really blame them for failing to keep an accurate calendar), and seeing how many concurrent threads it can spawn before Windows XP chokes (answer: over 700, since I've seen it grow to that many threads more than once both in some of the poorer 3.8.x versions and all the 4.0.x ones, before I killed the process so as not to find out how many it takes to crash XP and lose all my unsaved work in other applications, the loss of unsaved work in Limewire being by then a foregone conclusion)...

Maybe I can't blame Satan for not keeping an accurate calendar but I sure as hell can blame Limewire for not keeping my download list across sessions, despite professing to have done so since version 2.x. My official position is that I'm still waiting for this feature to actually be implemented.

Preliminary indications are that you have failed. 4.0.5 is slow the UI intermittently hangs, and I've already seen three "out of memory" errors on my 1GB system. During this time, there were never more than five items in the download list pane -- and the only likely culprit for any kind of "bad interaction", firewall software, was disabled the whole while. Commit charge 481/1622M. If it genuinely failed a memory allocation, it wanted over 1100M! (A smaller allocation from a fragmented heap might explain it, except the machine was rebooted less than an hour ago and there hasn't been time for the machine's memory to get badly fragmented yet. I've not done much since the reboot save a bit of surfing and launching Limewire and attempting to use it.)

If you mean things like spyware, viruses, and the like, the system's clean -- I scan new executables, I run Spybot S&D, and so forth. If there's any malware lurking inside my machine I'll eat my dusty, sputtery casefan for a crunchy after-dinner treat. :P

About the only thing I can think of that could possibly be the problem if Limewire itself isn't, especially now firewall software is eliminated as a possible cause, is the VM itself. But it's Sun's most recent version (1.4.2), so it's neither out of date nor a weird, dubious 3rd party VM that may not implement the full spec. In short, Limewire performs poorly on a commonplace OS with the reference implementation VM and a decent hunk of hardware resources to draw upon. I hate to think how horribly 4.0.5 must run, if it can even get out of the starting gate, on the many older P3-266 128MB Windows 98SE machines still floating around out there!