Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


All Activity

This stream auto-updates     

  1. Today
  2. When I tried out FF 53, I discovered that some of my add-ons got disabled. The problem was with "unsigned" add-ons. Usually these were legacy add-ons that continued to be maintained after Mozilla banned pre-WebEx add-ons, and thus could no longer get Mozilla to sign them. The biggest example was the legacy version of uBlock Origin, which I use because it offers more privacy protections than the WebEx version does on FF 52 and 53. (A couple were add-ons that were originally signed, but from which I had removed the signature in order to implement some hack.) In FF 52 ESR, unsigned add-ons aren't much of a problem. You simply set the about:config preference xpinstall.signatures.required to false and you're good to go. The unsigned add-ons will produce warnings in the about:addons page, but they work. You can even hide the warnings with an add-on like Classic Theme Restorer. But FF 53 is a "stable" release, and xpinstall.signatures.required doesn't work in stable FF releases. Luckily, there is a workaround, but it's a bit more complex than just setting a preference. The workaround at the link can be combined with @VistaLover's fix for re-enabling SSUAOs in Firefox 52: First, follow the instructions there; then add this JavaScript to the config.js file you just created: try { Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {}) .eval("SIGNED_TYPES.clear()"); } catch(ex) {} (I put it after @VistaLover's code, but it will probably work before it too.) One last thing. Since FF 53 doesn't expect to have add-on signing disabled, it doesn't have the yellow "warning" text that FF 52 ESR does for an "unverified" add-on. Instead, you'll see a scarier, red "This has been disabled" message. However, it has not been disabled; you'll still see a "disable" button which wouldn't be there if the add-on were already disabled. Luckily, hiding warnings (with, e.g., the Classic Theme Restorer add-on) will hide these scarier messages just as it hides the yellow warnings in FF 52 ESR.
  3. Vista's integrated AHCI driver would probably work. Hardware RAID would be a different story but I don't think it's present in that configuration. I also don't believe that Vista has any ACPI issues like NT 5.x does; it would be unfortunate if it did, considering that the modified acpi.sys actually comes from a later Longhorn build (50xx-52xx) I believe, and probably would be equally or less functional than the one with the released product. And for the 1050 TI, look for modified 372.70 drivers. They do not work well with DirectX applications though.
  4. Seeing this is a Coffee Lake CPU, partially, at worst. To install, you'll require... *VLite (to integrate drivers in a Windows Vista installation) **A newer ACPI.sys file (Windows XP did; Vista may not, depending on the vendor) *SATA/ACHI Drivers (These are Windows XP drivers, but they should work) *Modified Windows 7 driver for your Intel® UHD Graphics 630 (this may not work because it's meant for 7) I do not recall any forum post mentioning getting the 1050 TI to work on Windows Vista...I do not believe modified drivers exist for the 1050... Also, you'll need to provide what sound card you are using. Do you happen to be using a wireless card by chance? I'm also not aware whether the video card I provided will provide chipset drivers or not.
  5. Any way to directly contact the developer?
  6. Delete the "s" in the URL HTTP:// instead of HTTPS:// and it should download fine. I have to do that every time.
  7. Wondering the same. Symbols download fine, but I am still getting the DWM compatibility error. I have deleted and downloaded new symbols about 4 times and it does not change anything. If I click "cancel" instead of "retry" then Aeroglass works on 1909, but I have to do that every time do a logon.
  8. I don't understand what you want. If you don't want them to move, then don't move them. Just because they "CAN" be moved to a new location, doesn't mean they will or can move by themselves. Or do I not understand the problem? Cheers and Regards
  9. @VistaLover, it turns out it was because I was at 100% zoom on my 1024x768 screen. It does appear when I zoom out a bit.
  10. Yesterday
  11. I came across this YT video , I hope it's useful ! Cheers !
  12. @jaclaz Thanks a lot for your efforts! The results of a few dozen experiments are suggesting that you are right with the attribute-"thing" I did some new tests with help of my old Diskedit, with maybe conclusive results, at least on my system (don't try this at home......). On a newly FAT32-partitioned 4GB USB-drive with only one primary partition, I wrote a volume-label with MS-DOS 7.1 LABEL.EXE. This gave the volume-label as first Directory-entry with attributes A - - - V and date and time of writing. The volume-label was further written to the Bootrecord in Sector 0 and to the Backup-bootrecord in sector 6. Changing volume-label in Bootsector after erasing in Directory was useless, no output from MS-DOS 7.1 VOL, DIR, LABEL.EXE and FDISK.EXE anymore. Grub4Dos gave with vol (hd0,0) following output: "(unsupported)". Writing volume-label with vol --write (hd0,0) GRUBDOSNAME gave this volume-label as second Directory-entry only, with attributes - - - - V and as date 0-00-80 (whole entry is marked "RED" by Diskedit, but okay after writing a valid date). Output of vol (hd0,0) was still GRUBDOSNAME In MS-DOS 7.1 VOL, DIR, LABEL.EXE and FDISK.EXE displayed all the first volume-label written by LABEL.EXE. As soon this volume-label was erased by setting first byte to E5, they displayed all the second label written by Grub4Dos. Rewriting the volume-label with LABEL.EXE erased the label written by Grub4Dos, LABEL.EXE set first byte to E5. Grub4Dos showed this label as sRUBDOSNAME (Greek 's', can´t show it in this post) and was willing to write a new volume-label. Deleting volume-label with LABEL.EXE erased both, and the directory-entries were overwritten after copying files to the drive. On my 1GB FAT16 USB-FDD: same results, although I am not fully sure if LABEL.EXE erases the second volume-label if it´s on an other sector of the Root-directory. Tired of testing I never ran into problems while using Partition Magic 5.01 because this program write volume-labels without the Archive-attribute! I hope you are confident now with my comment "# vol --write not compatible with labels written by FORMAT or LABEL", presumably the MS-DOS 7.1 one´s - the post is about Windows 98
  13. Thanks for all the media player suggestions. Still checking stuff out, downloaded and installed many. Some versions don't work or can't find the required old version, don't play all file types, mostly music oriented, too commercial, too cluttered, too complicated, want to call home, etc. Will casually keep looking, may max update WMP. Must say downloading and installing random files from the internet feels dirty, after almost 15 years of utilizing centralized open source repositories, coding and compiling much of my own. Almost wore out add/remove, cleaned up temp files and registry, must take long shower :) Added a Dillo search engine to find information on this forum: search_url="MSFN_Yahoo https://search.yahoo.com/search?p=site:msfn.org+%s"
  14. Instant messaging platform, I guess it's sorta how (old) skype works in terms of it's function. Upwards of 300 million users IIRC https://telegram.org/
  15. Thanks for the reply. I will try on Windows 7, as I just could not get it working on Vista with any of the browsers found in this topic. Thank you, I did all of this and could not get it working.
  16. The apps by Nirsoft is portable can I make Unportable?? I have sent all RegDLLView as an example. John RegDllView.exe
  17. Sure you can: Do you, by any chance, have the sidebar displayed?
  18. OK, since you can't add code when editing a post, here it is: [spoiler] [/spoiler]
  19. Thanks, but it's useless when it goes live (i.e. in your post, I can only switch between "Hide contents" & "Reveal hidden contents"; you need to document (pun intended!) this function by stating plainly the code to be used inside MSFN's post editor...
  20. Of course, I can't deploy Waterfox in my Vista SP2 x86 laptop, but a targeted GitHub search reveals plenty : https://github.com/MrAlex94/Waterfox/pull/566
  21. It's undocumented, but you can try this:
  22. Detailed explanations are always my preference; thanks! Of course I also understand why you might not have wanted to go into such detail the first time around. (It's too bad MSFN doesn't support a "spoiler" tag - that would have been a perfect use for it.) (Note: henceforth I will use "AM" as my abbreviation for "Add-on Manager," so I can reserve "AOM" for "Alliance for Open Media" and its AV codec.) So from the above, one can infer that NM 27, NM 28, as well as "official" PM and Basilisk, none of which support WebEx add-ons, all use the Tycho AM, which displays add-on version numbers without the assistance of an add-on like CTR. OTOH, any browser supporting WebEx add-ons (Serpent 52/55, Firefox 52/53) by necessity must use the WebEx AM, which does not display add-on version numbers unless "coerced" to do so via an add-on such as CTR. However, that little wrinkle aside, nothing seems to stop anyone from running the newer CTR versions on Serpent 52. At present I'm not aware of any "killer" features that would make this worth doing, but at least we can experiment! Waterfox (Win 7 and 64-bit CPU required) would seem to be the oddball here, as it does support WebEx add-ons (as well as classic ones), so one would think it too would use the WebEx AM, and therefore wouldn't display add-on version numbers without CTR's "help." I must therefore conclude that the Waterfox folks developed their own fix for this issue. (Since it appears to be merely a .css issue, I suspect it was a rather simple fix.)
  23. One method is to have the 5 1/4" at the end of a long floppy cable and a 3 1/2" in the middle named A and B drives. The drive on the middle connection run at twice the access time as the 5 1/4" at the end so the 3 1/2" had to be a good one, a >=2002 model. Another method is in parallel as picture shows. The prerequisite is that the 5 1/4" has to work by itself. This usually requires a machine to operate with a maximum of 66 - 83 FSB. The key board access time had to be set to 6 stokes per second or less if BIOS had adjustment. This slowed down access rate to the floppy drives so that the 5 1/4" had a chance.
  24. ... But don't actually pay attention to what other people made the effort to post ... I did mention the reason in the part you chose to ignore: When MCP chose to remove WEs support from UXP and official Basilisk, it was a perfect chance for them to switch Basilisk's AOM (WebExAM) to the one present in Pale Moon (TychoAM) - PM's AOM dates from a pre-Australis era, has no support whatsoever for WEs and, as stated by Aris, displays addon version number by default. But it was decided (by popular demand here) to keep WEs support in Serpent 52.9.0, that meant staying with the original AOM shipped with UXP, pretty much the same as the one in FxESR 52, which supports WEs but doesn't display addon version number by default (an additional legacy extension is needed for that, e.g. CTR). In CTRv1.7.8.2019.xx.xx, Aris removed the .css code that enables the WebExAM to display addon version number (by selecting that option in CTR), since it's now a native feature of the TychoAM present in official Basilisk. Please read for more info: https://github.com/MoonchildProductions/UXP/commit/2cbbc5d https://github.com/Aris-t2/ClassicThemeRestorer/issues/402 https://github.com/Aris-t2/ClassicThemeRestorer/issues/408 Regards Addendum: Mozilla had intentionally removed the default display of AVN (addon version number) in the Australis[later WebExAM] AOM back in Firefox v40, when Bugzilla bug1161183 landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1161183 This was again an unnecessary move, a type of "chop head to get rid of headache" approach, since the bug originally wasn't about AVN per se... https://bugzilla.mozilla.org/show_bug.cgi?id=1161183#c10 Remember, that was back in 2015 and already Mozilla devs had an opinion on what is of use in the browser GUI to most users, the rest were deemed to be few... I guess @roytam1 would have to revert that bug in both Serpent 52+55 (which use WebExAM) for CTRv1.7.8.2019 to be used as wished by @Mathwiz; but I don't think it's needed (now me sounding like a Mozilla dev...): if one is adamant on installing CTRv1.7.8.2019 in Serpent (which, I emphasise, is maintained with only official Basilisk in mind!), may co-install the following legacy extension: Version Number in Add-ons Manager 1.10 (by magicp), recoverable via CAA (caa:addon/addonvernumber) (Hope this time post is NOT ignored... )
  25. it seems that direct link still works, so it's something on the download button or something. http://www.glass8.eu/files/setup-wrs-1.5.12.exe
  26. im facing the same issue with all downloads.
  27. Telegram? Haven't heard of that before? Can you explain what it is?
  1. Load more activity
×
×
  • Create New...