Jump to content

Drugwash

Member
  • Posts

    1,848
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    France

Everything posted by Drugwash

  1. Because we can! Now seriously, the patch operation itself has been tested on a wide variety of driver versions just to make sure the logic of it stands firm. At some point we may receive requests for different language versions and the logic may work for them as well. Or not. Nobody needs to patch drivers that don't need patching. But it's good to have choices - it brings responsibility with it. Anyway, there is a version limit according to the feedback and that limit can be overridden if desired, for testing purposes or whatever. By the way, we still need testers for all flavors of Win95. And hopefully Mr. Loew will come up with a working version of the code for ME.
  2. We're working on a generic patcher that can (at least theoretically) do the job for almost any driver version. It's almost done but it has only been tested on English language drivers, from 45.32 to 82.69. Should be ready for next week at the latest unless something interferes.
  3. Well, technically you're right, we who realize the truth beyond the mascarade are probably the few. But I didn't want to take such position of superiority as I still consider myself - and by all means I am - a simple person.
  4. Great talk! And true. But we, the many, do not own our own lives, do not own the product of our own minds. So how could we change the world for the better…?
  5. Reminds me of the Michael Hastings case. Maybe Paul Walker too, althouth naysayers would immediately connect the 'Fast & Furious' movie franchise to the event saying he just asked for it. One of the reasons I would never own or drive a car and as much as possible avoid being a passenger in one.
  6. Overwriting existing data may be risky. Maybe I should put the patcher on hold until problems get sorted out. Still, it could help for testing, instead of hex editing. Well, I'll just wait for a while.
  7. Apparently this is getting complicated. We need extensive testing under Windows 95, 98, 98SE and ME in order to find the working code for each system and driver version combination. I will design the patcher with the ability to load specific patch code according to the current (or selected) OS version and driver file version. For that we need verified and working code for drivers starting with 77.72 to 82.69, each of them tested under Win 95, 98, 98SE and ME. Hopefully videocard series would not add any more complications to this. There is one more issue I just stumbled into: the available space for extra code may be extremely scarce for certain driver files. The 55.64 (even if that particular version is out of scope) couldn't hold the 15 bytes in the first code variant, not to mention the second one. If code grows much larger, we may have to find another address with enough empty space or simply abort the project, unless the files can be recompiled, which I very much doubt since the code is not publicly available.
  8. Hm, commandline parameters... So DOS-like. We're in Windows now. I'll try to add an 'ignore driver version' option. I'll probably ignore videocard version completely too, since one may even attempt to patch a 9x file on a 2000+ system with a non-nVidia card anyway.
  9. Your code above matches 100% the one generated by the patcher. I've applied the patch to other (lower) versions as well but still have no way to test them. So far I have: 45.32 (my current 98SE driver, can't use a higher one as it disables AGP texture), 53.04, 56.64, 61.76, 66.94, 71.84, 77.72, 81.85, 81.98, 82.16, 82.69. @ dencorso: Should I lower the driver version minimum to 77.00 or is there any even lower version that may need patching? I'm too lazy to read all those topics you linked to.
  10. No worries, I know you're very busy. The translator can be found at my CloudMe repository in my signature below. The SIBT folder. Hope it helps.
  11. Those missing NDIS APIs indicate a newer NDIS version which may very well be unusable under Win9x. Guess we hit a dead end here, unless Dell driver mentioned by farfigs11 above could somehow be patched. That is assuming there are no other hidden (run-time) dependencies.
  12. Do you want me to update the translation application or does it still work correctly for the newest SiB++ version? I can't test any SiB version since I have nothing higher than XP around me.
  13. OK, so I guess I should settle for a minimum driver version of 80.00 and card version 6000 (round figures). Well, probably not tomorrow since it's my birthday, but sometime next week I'll add those checks. Thanks!
  14. Yes, that was to be expected. The code doesn't appear to work as it should (at least on your machine), but additionally there was that calculation bug that jumped to a wrong location leading to the protection error. The 'red fix' was only for that issue, for the rest is up to Mr. Loew. However, I've been working on an automated patcher based on the code pattern presented in first post and so far it appears to work correctly, but we'll have to wait for some additional fixes. While I'm here, does anybody know for sure which driver version is the very first to exhibit the shutdown bug so I could set the lower limit for the patcher? Also, which is the lowest card version that exhibits the bug in conjunction with the drivers? I'd like to set some kind of frame so as not to unnecessarily patch driver versions other than the ones that do need patching. Of course, all that if Mr. Loew agrees to the patcher - after all, it's not my code.
  15. @ schwups: There may be a calculation error in the relative jump for 82.16 (if my logic is correct ). Please try to replace the values in red below: 31FCAC: 3C 32 75 02 B0 52 89 44 24 04 E9 45 4E E5 FF to 31FCAC: 3C 32 75 02 B0 52 89 44 24 04 E9 15 4F E5 FF For what it's worth I've used the XVI32 editor, simple and handy (click left pane, type hex values, click 'Save').
  16. There are inconsistencies between http and https with their site. I have HTTPS Everywhere in Firefox which forces secure connections where possible and I see a https connection, but if initiated as https, a connection to CloudMe will fail. It has to be initiated as http. I've modified the link above accordingly, hopefully it'll work now. If not, try clearing file name from the link (final slash included). The whole driver package is almost 20MB. I can't even attempt to send it over e-mail earlier than the 20th of the month when my bandwidth gets restored to its full capacity. If nobody else provides you with the package until then, I will try either uploading to CloudMe (in case more people need it) or attaching to an e-mail to your Hotmail address.
  17. Here it is nvcore.vxd 4.14.10.8216: link (hope it works, CloudMe had some issues lately)
  18. Maybe the memory range needs to be tweaked in some inf, or maybe there's a hardware conflict (BIOS can't assign specific range) so another PCI slot should be tested (is it a PCI device?) Sorry for not being of much help, I have no Wi-Fi device whatsoever around the house.
  19. Great news, thank you! I've patched the only machine I have that uses 82.69, over the network, live, without a hiccup. Nothing blew up on a reboot. Unfortunately I have no series 6/7 nVidia card to test the effectiveness of the patch but at least it doesn't bother the GeForce2 MX440.
  20. I see. So on my 98SE machine the official build works because KernelEx takes care of TryEnterCriticalSection (I looked through the sources). Guess it's worth stating that KernelEx users on 98SE/ME can use official builds of SQLite provided the library is set to 98SE or ME compatibility, respectively. Non-KernelEx users should use these libraries fixed by blackwingcat. Arigatou gozaimash!ta! (somebody should seriously look through the board filters because NOT all words that CONTAIN sh!t are actually profanities )
  21. Thank you! What exactly is the problem with official SQLite builds? With KernelEx installed and set to Windows 98SE compatibility, official builds work on my machine. Is there any set of tests available to thoroughly check the behavior of official+KernelEx builds versus your fixed builds?
  22. Sorry for replying so late, been busy today. My 98SE system is nine years old and it has undergone a lot of replacements and additions during this time. I have KernelEx 4.5.2 and Kstub822 (which may not be of importance in this case) plus Auto-Patcher and Revolutions Pack. Most likely I already had DNSAPI.DLL installed prior to installing CloudMe, but my memory is fuzzy so I can't tell for certain - it's also possible I have "borrowed" it right then from somewhere. The version of DNSAPI.DLL installed on my system is 5.0.2181.1, said to be coming from Windows 2000 and it uses 'default' KernelEx settings. It also has five dependencies: msvcrt.dll, advapi32.dll, kernel32.dll, wsock32.dll, rpcrt4.dll. If possible, try to profile the CloudMe executable through Dependency Walker, see if there's any other missing files or APIs.
  23. - Create a duplicate folder of C:\WINDOWS\KernelEx named, for example, KernelE0 (with all files inside) - Install newest version; old version will remain intact in the newly created folder above To switch between versions: - go to DOS or Safe Mode - rename the KernelEx folder to something else (such as KernelE1) - rename the KernelE0 folder to KernelEx - reboot normally On each switch just remember the name of the alternate folder will be either KernelE0 or KernelE1. To check which version you're running at any point in time, just run verify.exe from the current KernelEx folder.
  24. Yes, that's the right place, thank you. It's a sticky post so I could've found it quite easily... if I remembered that. Theoretically there's also the problem whether the BIOS supports 48bit LBA or not. For completeness sake we can count in the possibility that the drive has been partitioned on another machine (48bit LBA-compatible) and then transferred to current machine. However, in this particular case an ICH7 board should support 48bit LBA since the chipset was first released in 2005.
  25. Maybe the respective newer filter has unfulfilled dependencies. Please check with Dependency Walker or any other similar utility and see if there's any missing dependency file(s) and/or API(s). My version of JPEGIM32.FLT is 2003.1100.8165 and comes from MS Office 2003. I don't have any themes installed in the PLUS! folder so can't test, but placing a JPG image in C:\WINDOWS\WEB\Wallpaper does show it in the Display Properties > Background >Wallpaper list, so I guess the JPEG filter does work. However, as MrMateczko noted above, the service packs are usually only for English versions of the operating system - unless other specific language versions are available - and mixing different language files can lead to unwanted results. Anyway, thank you for the solution in regard to the filter issue. In short, for non-German speakers: extracting the original JPEGIM32.FLT filter from the Windows 98 CD and replacing the newer filter from the service pack with the extracted original one fixes the issue of missing JP(E)G-type wallpapers from the Display control panel when Desktop Themes are installed.
×
×
  • Create New...