dencorso

Out of respect for your hard work, I'll apply myself some more to this problem... Let's compare, from your post #55, task 1 to task 2( a & b ), limiting our analysis to Opera: i) Bjork "All is Full of Love" played perfectly in both tasks. ii) MGMT "Electric Feel" didn't play well in either... it seems to have problems. iii) All other video clips played well in task 2, but had problems in 1. My conclusion is Bjork's video elicits only "good behaved" SSE instructions (i.e.: those which cause "Invalid Instruction Faults", henceforward simply "IIFs" and cause RLoew's patcher to spring to action); all other video clips appear to elicit also some "bad behaved" SSE instructions, which are misunderstood by the Pentium II into doing silly things but never cause IIFs (so RLoew's patcher cannot help), and this is why they don't play as they should with Flash 280, but do so with Flash 47 (because it is SSE free). MGMT "Electric Feel" seems to be worse in that it is heavy on the internet connection, probably due to a high framerate (it played somewhat chopply for me even with Flash 10.1.82.76 / IE8, under Win XP SP3). Things get worse on Firefox or Netscape possibly because the same Flash .dll playing the same video clip on different browsers apparently causes different execution paths to be followed inside the .dll, with the result that more "bad behaved" SSE instructions come into play with the above named brosers than with Opera. =========== While this model (= working hypotesis) seems to explain all the facts considered, it's still just a guess, at this point. A detailed study of the machine codes for the SSE instructions is required, to see which can be misunderstood for MMX machine codes, leading to which results. Then those instructions would have to be sought out in the actual code and patched by hand (= cold code patching) instead of by warm code patching (i.e.: execution time patching, which is done by RLoew's patcher). Once all "bad behaved" SSE instructions were dealt with, by using RLoew's patcher with the cleansed Flash 9.0.280.0, one should be able to play OK every video clip in YouTube and elsewhere. So this model is testable, but, at this point in time, I have not enough information to truly evaluate how time consuming the cold code patching phase would be, nor whether are there feasible patches for everyone of the "bad behaved" SSE instructions, much less how many different "bad behaved" SSE instructions do exist, and of those, how many different instructions actually exist in the code of Flash 280. Moreover, how does a processor actually behave when faced with instructions it wasn't designed to understand is, of course, undocumented behavior, which requires testing to find out. And this is why I'm somewhat despondent we'll ever solve this problem effectively just by software. =========== @jds: do send RLoew an e-mail about it, in case he doesn't post again here soon.

OK. I see I had misunderstood you. Thanks for clarifying your point. And, sure, take your time in testing it. I agree such a fix must be solid. Keep on the great work!

I'm anxiously waiting for larryb123456 to report his results after the upgrade to the Pentium III processor, because: 1) I'd be glad to know it solved his issues (and I bet it'll). 2) It would prove beyond reasonable doubt that there are instructions in the Flash Players > 9.0.47.0 that are not correctly executed by the Pentium II, but which do not elicit a "invalid instruction fault", which I think is the only reasonable explanation for the results reported by larryb123456 with RLoew's real-time patcher VxD.

For what it's worth, no it's not. The latest usbport.sys is v. 5.1.2600.5778 from KB968764.

It's done! Microsoft offers a patch for it (XP+) since late July as KB2286198 (MS10-046). Please refer to cluberti's answer below, regarding this matter.

Well, sort of. It's complicated... Read this thread, though, and you'll know what is there.

The best strategy is many at once: full partition images burnt regularly to DVDs, full partition images saved at finer regular intervals to a big external HDD, two HDDs with independents OSes in system partitions and one data partition in one of them incrementally backed-up to another one of the same size in the other. And, at least one aditional partition in one of the drives for discardable data (which can be lost without problems) and the page file. It's time consuming, but the more paranoid you are, the safer you get.

Well, for what it's worth, me too! I still keep a rare K6-III machine working, but I'm thinking of decommissioning it before this year's end or a little later. However, it was so hard, way back when, to get the K6-III, that I keep postponing it for sentimental reasons alone. Nowadays it is used for little more than word processing, if at all used. It once was my primary machine, and I thought it was lightning fast! Now it seems slow as a drunk turtle. Sign of the times. But it nevetheless works...

Reply to Post # 75 Question 1: I don't know. "markup" = html You can display the true "embed URL" using code tags. Like this: http://www.youtube.com/watch?v=tvoEZXop4zM&NR=1 Question 2: I guess so. Step 4: Yes. Step 5: No. It depends on whether the local processor can interpret the instructions inside the *specific* FP version installed, no matter what anyone says or thinks about it. This would mean having access to Adobe's unpublished documentation or performing a full reverse engeneering of the player. The former is improbable, and the latter too much time consuming to be worth it. By tests alone, the nearer to it you might get is to reach a theoretical hypothesis of what the COMPLETE step sequence you're asking about is, after performing an impressive amount od tests... so that's even more time consuming. Yes. The SSE is reached and the processor issues an "Invalid Instruction Fault" which is an interrupt that transfers control to a handler. If the handler is the default windows handler, you'll have a BSOD or even a crash. If it's RLoew's patcher it'll patch the code in memory to eliminate the invalid instruction by substituting it by code the Pentium II can execute and tranfer control back to the flash player at the point where the SSE instruction originally was. That would be it. Unless... Unless the Pentium II thinks it understands the instruction and performs some unpredictable action, instead of duly issuing the "Invalid Instruction Fault"! I think this is the reason why RLoew's patch doesn't actually get flash to work, although it takes good care of eliminating all crashes/BSODs. Observe that I didn't say here one single thing that had not been said before either by myself or by RLoew. I've just rephrased part of it and integrated it all in a single big picture. And yes, the forum software has been updated, and the new version has the player displaying ability, which the former versions did not. ========= Reply to Post #76 Because the Pentium III knows SSE. ========= Now, you had a simple problem: how to be able to use Flash v. 9.0.280.0 We offered you two possibilities: 1) A software solution (RLoew's patcher) that treated the disease we diagnosed but did not cure the patient (so it was not enough). 2) A hardware solution (the drop-in Pentium III) that is guaranteed to solve your issue (at least as far as V. 9.0.115.0, that is, and using videos that can play with it) but that, in solving your problem will not allow us to ever diagnose what more was needed for RLoew's solution to work. However, in the unlikely case that even the Pentiun III prove not to be enough, then we may infer RLoew's patcher may have been enough (but the patient's illness is even more serious than I thought). For me that's quite enough. If you become able to use 9.0.280.0, on substituting the processor, I'd consider the original problem solved, and move on. Now, with all due respect: The number of users still running SSE ignorant processors is even smaller than that of 9x/ME users, which is already small. If 9x/ME has a future, which I still believe it does, that will require us to do our best to keep it compatible with contemporary hardware. We simply cannot afford to cater also for hardware that is falling out of use faster than the OS we're trying to keep viable, unless that doesn't require a considerable effort. Just as there's a time to sow... and a time to reap, there's also a time to keep trying... and a time to let go, IMHO. Of course, YMMV, though.

To make sure one searches the forums before posting, perhaps?

I use a Microsoft Intellimouse Optical, too. However I do so using the PS/2 adapter and use the great Kensington MouseWorks (v. 6.11) to program the buttons and chording (two buttons at the same time) clicks (it only works for PS/2 mouses, though, since it'll recognize it's not a Kensington mouse [and refuse to work] if you try to use it with a USB mouse).

No problem! Threads merged! It's in the upper right of every page. There is a gear to the right of the search box. This brings up advanced search.

75-80 degrees Celsius? Wow! That's great for cooking! You'll be able to make quite nice thin steaks on it! But it's no wonder the HDD disconnects. What *is* wonderful is that it actually reconnects when it cools again. It should by now have died already. Stop using it and get it a good HDD cooler, before you try to image it or do any other use-intensive activity with it.

Dave-H succeeded in using 512 MiB, but he uses RLoew's RAM Limitation Patch. While the patch is not for free, it's not expensive either, *and* there's a free demo for you to try. May I suggest you try it, before giving up, Jolaes? Install it with the /M option, like Dave-H did, and let's see what happens. You may get it at RLoew's Homepage Then again, Cyker already uses RLoew's patch and it's not enough, in his case... But here it's one case where the fact that YMMV can work for you, perhaps.

IPB 3.1.2!!! Great! Thanks, xper!

Wow! Trumpet Software! Now, that's really a blast from the past! Their products are still avilable, but not for free, though.

Did you try to go to the Device Manager -> "Floppy Disk Controller", go to Properties -> Resources, click on "Set Configuration Manually", click on Change Settings and select a new range from the list that shows "No devices are conflicting" in the Conflict Information Box, click OK, OK, and reboot? Were you unable to change anything because it is grayed out?

System Restore can also be transplanted to 98SE, if one so wishes. I don't see why one would want that, though.

That's correct. The ability to deal with 1150 MiB for 98SE vs 1995 MiB for ME is hardcoded in VMM.VxD and the VMM.VxD from ME cannot be coerced to work with 98SE, nor vice-versa.

Win ME can natively recognize about 1995 MiB RAM (but not 2 GiB or more) vs. Win 98SE that recognizes just about 1150 MiB, natively. Win ME has WFP (aka System File Protection) which is a nuisance that has to be disabled (by using OPPCOMME, for instance) and hasn't native access to Real-Mode DOS (although it can be restored or unhidden). IMHO, the advantages of ME are hands down outweighted by its native annoyances. I second jaclaz: Win 98SE (preferably with 98SE2ME) is the best overall choice. But, as this is a matter of opinion, no matter how informed it may be, YMMV.

I'm not backing off, now, really... the point is I didn't question a Pentium III was enough (to play FP > FP 9.0.47.0), from what I read, until RLoew posed his question. I mean, Flash 9.0.115.0 is from Nov 21, 2007... I already had an Athlon XP by that date... So I cannot really (first-hand) know it. But, by inspecting the code of the Flash 9.0.115.0 plugin, one finds the SSE instructions are there, so that makes a Pentium III the bare minimum requirement. And this squares with all I read around in those links halohalo and I gave you, so I never questioned it until RLoew's question taken together with your results helped it dawn on me that it just may not be enough. But we cannot know for sure, unless you move over to a Pentium III. I bet it *is* enough, and the patcher needs to address some other issue we're not yet able to pinpoint, to enable a Pentium II to behave as desired. But I cannot dismiss the possibility that a Pentium II plus the patcher do emulate perfectly enough the Pentium III, and that even it would not be enough to play those test videos you selected as our test suite. @RLoew: Have you read this and especially this?

My point in suggesting the Pentium III is answering RLoew's question: Do these videos play with a Pentium III? If they do so correctly and without issues (without the patcher, of course), we'll know there is more that the patcher must know to work right, even if that more are not "invalid instructions". Now, if they don't we may infer that the patch achieved simulating a Pentium III out of a Pentium II well enough, but that even a Pentium III is not enough to actually have those videos play correctly. We already do know that the minimum system requirements listed by Adobe for Flash 9 are true only up to 9.0.47.0... for all other versions they are not the true minimum requirements, and it's possible not even a Pentium III may be enough. That's why I said your machine will learn what to do with SSE instructions, on processor upgrade, but I did not risk saying it would learn how to use the newer versions of Flash.

Well... it can be quite close, really, now that you mention it... If one admits the Wikipedia's List of Pentium IIs to be accurate, there is only *one* type of Pentium II 450 MHz: the Deschutes core Pentium II 450 MHz (512 KiB L2; 100 MHz FSB; Slot 1; 2.0V) from Aug 24, 1998 and if, by the same token, one admits the Wikipedia's List of Pentium IIIs to be accurate, too: the Katmai core Pentium III 450 MHz (512 KiB L2; 100 MHz FSB; Slot 1; 2.0V) from Feb 26, 1999 should be pin-to-pin compatible and, in every aspect, a drop-in replacement for larryb123456's Pentium II... Now, if larryb123456 would be willing to actually embark into an actual processor exchange adventure, it would not only enable definitively his machine to understand and execute SSE, but would also provide the test results RLoew needs. And there happens to be one on sale right now on e-Bay for about US$4!!! @larryb123456 (answers to your questions on post #63): #1) Yes. #2) Under ideal conditions, its "education" would become *permanently saved* on the copy and, provided you "educated" it thoroughly enough, the dynamic patcher would not be needed anymore. But you'd need a criterion to decide how much is enough.

By "setup" I meant the totality of your computer, your operating system, the browser in question and the flash plugin in question, all taken inclusively. My remark is a very general one, almost a spelt out thought, put out half for myself, just to point out to you and RLoew along which lines I was (and still am thinking). All this vagueness reflects the fact I still cannot pinpoint the origin of your problem (if it is in the way the plugin is coded, a solution may be found, whereas if it lies on the interaction of the plugin with all those other components, then it's unlikely we'll ever solve it and get it to work). Now, since audio and video must be buffered before playing starts, I'd say some buffer filltime is getting much longer than expected, causing the loss of sync you've observed.

Hi, larryb123456! It's a lot of info... I think I'll have to digest is for some time. But it's already clear to me that: 1) RLoew's dynamic patcher doesn't cause any unforeseen adverse effect to your system (as the experiments with Flash 8 and Flash 9.0.47.0 have clearly shown). 2) RLoew's dynamic patcher in the current form is not enough for the higher flash versions to work OK. But it's not completely clear to me why. RLoew's dynamic patcher solves effectively the problem of the missing SSE instructions but that alone isn't enough, although it allows those versions of flash to run (even if erratically), but not to run correctly. But it should be enough. For the moment, all I can say is I'm flabbergasted. I sure hope RLoew can guess what's happening. If 9.0.115.0 worked but 9.0.280.0 did not, I might have an expanation to the observed facts, but both seem to work equally badly, so whatever happened between 9.0.47.0 and 9.0.115.0 cannot be ascribed solely to the SSE instructions... there must be more to it.