Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/29/2020 in all areas

  1. Moonchild's stance is now "if the mountain won't come to Muhammad, then Muhammad must go to the mountain", as expressed (along with "name calling") below: https://forum.palemoon.org/viewtopic.php?p=200402#p200402 and further down in that thread:
    2 points
  2. Out Pale Moon 28.14.0. Release Notes: https://www.palemoon.org/releasenotes.shtml ***** = https://www.palemoon.org/redist.shtml
    2 points
  3. Yes but they probably couldn't easily remove all the other updates and just leave those two Office ones! I suppose it's good to know that the update archive is still there and hasn't been trashed (yet) and it's just the automatic accessing of it that's been disabled. I'm assuming that Microsoft Update doesn't just get its updates straight from the Update Catalogue, which is still manually accessible of course. As Vistapocalypse says, maybe it was just a mistake!
    1 point
  4. ...because Dell is Dell, they simply have their own ways to do things AND mis-documenting the *whatever* they do, not necessarily worse (nor better) than any other OEM/laptop manufacturer, only *somehow* different. jaclaz
    1 point
  5. Yes and no, Dell is Dell, it is very possible (actually probable) that your touchpad is actually an Elan one and I thought wrongly that it was a Synaptics one. jaclaz
    1 point
  6. Could you explain what this means? Is this a v28-only build preference Please read below: that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation. ... and will go if I remember to do this. As to: I'm not currently using NM27, but do you now (i.e. in latest builds) see extraneous accessibility files inside its main directory? FWIW, one can always consult built-in pages like "about:buildconfig" to read build-time configuration flags...
    1 point
  7. It didnt start with your files the drivers are just broken on vista , your files dont fix those errors , there are many instances where i get this error , IE9 64bit , Steam games , sometimes in windows score assessment (winsat i think) , All of them 64bit , 32bit dxdiag works fine , while 64bit crashes https://imgur.com/a/fnYuj2c one thing to note is that , the steam games would just crash without your modified files , but with it , it would probably run with proper drivers since it crashes on the nvidia D3D10 dll now.
    1 point
  8. @VistaLover. thanks for the download manager fix. as to testing Mypal vs New Moon. it is not my intention to switch browsers. just was curious as to how Mypal works with the "instances " page. am happy to see that this is a more friendly board compared to the upstream one. and a big thanks to roytam1 for maintaining New Moon and other weekly builds. did not mean any disrespect. regards.
    1 point
  9. I still find Vista as the apogee of Windows design-wise.
    1 point
  10. Drivers will take awhile (need to really extend ntoskrnl/ntrknlmp), especially newer NVIDIA drivers that are needed for RTX and GTX 16xx. I'll have to add like 40 functions for the 41x drivers. Some are very complex and there is no guarantee of stability.
    1 point
  11. So I was checking out this other bank and their procedure to log onto their online services is even more convoluted. And looking at other banks' offerings...the more, I look, the less I'm sure where to go from here. I forgot to mention, there is some extra glitch with Magisk on my device; Magisk normally checks the ro.build.tags prop and sets it to release-keys if it was set dev-keys or test-keys, custom ROMs have it set to one of the latter two. It's written in /system/build.prop file that is generated during build process, which may be modified with rw access to /system. The glitch is when Magisk modifies it during runtime, getprop utility returns the updated value, but a programmatic check through Java still returns the old value unless you modify build.prop file directly. I don't know whether that app checked build tags first or the presence of busybox binary, which, BTW, is actually present on certain official ROMs! I just identified the relevant blocks of code by taking its APK file apart with APKTool. It looks like root checks span across both Java code and one of the bundled native libraries. So the things that I identified are successfully hidden on my phone, at least undetectable by Native Root Checker and RootBeer Sample apps. I also tried registering with the previous version of the banking app, which, in logcat, specifically mentions "negative root check", but no luck, log indicates their server returned some error code. Of course, they could be blocking older versions. Back to the current version, I also tried changing my device's fingerprint, didn't help neither. The thing about blocking my phone's serial number is pure speculation on my part, but this could be it as part of its code does read it. I figured the serial number is passed to the Linux kernel via androidboot.serialno=xxx paramater by device's bootloader. There's also possibility that some hole still exists through which root may be detected. One such hole is known, but can be avoided by using Magisk fork with modules functionality stripped, which I ended up installing, though I haven't found that it's actually used by the app. I guess they could also block the numeric ID they give to their customers to activate the app, but then even using different phone wouldn't make a difference... I also messed around with various versions of Android-x86 on my laptop. It has its own quirks. Good to know ART cache (Dalvik cache in older versions, but still residing in /data/dalvik-cache in newer versions) wasting a lot of space is the problem of Android 7.x in general. I haven't been able to pass SafetyNet test on it, not even the basic one, so there goes the idea of using PC port of Android for that stupid app. Not much positive is written about passing SafetyNet on Android-x86 AFAIK, just some guy hinting using his Magisk module safetypatcher supposedly helps, which just changes phone's fingerprint in a different way during runtime. But since changing the fingerprint directly in build.prop isn't evidently a problem, since I could do it on my phone and still pass the check and the author of MagiskHide Props module, which also changes the fingerprint, says it won't help if one is unable to pass even the basic check, that's just another dead end. Finally, removing Magisk on my phone = SafetyNet check not passing due to custom ROM Downgrading to latest official ROM (Android 4.4.4) = inability to run the banking app at all since Android 5+ is required
    1 point
  12. Looks a lot like W7, which is cool. This is my current theme: Only missing Glass8 to add transparency w/ blur and live reflections from Vista.
    1 point
  13. Isn't the default in Android called "Browser"? As for skipping commits, ask the Linux and BSD folks (people who know what they are doing) about the subject,rather than Tobin and that bunch. Basically, under open source licenses you're not obligated to integrate commits or anything else you don't want in your work as long as you are in compliance with the license.
    1 point
  14. So far, the following x64 DLLs have been extended: kernel32.dll dwmapi.dll ntdll.dll (wrapper, named ntext.dll) ole32.dll shell32.dll user32.dll uxtheme.dll As a result, Windows Media Foundation from Windows 7 Platform Update was successfully transplanted. The same could be done for Windows 7's crypto binaries. Based on something I did for Windows 2000, you will have take into account the associated binaries like crypt32 and secur32, and possibly dssenh.dll.
    1 point
  15. It's perfectly usable. To use it, just do something like this: The next kernel32 update will call ntext instead of ntdll as well.
    1 point
×
×
  • Create New...