All Activity

So we may safely assume, no support for XP was ever inttended. Look here, https://aidanfinn.com/?p=13179 "Why Windows Server 2012 Hyper-V VHDX 4K Alignment Is So Important The current VHD driver assumes a physical sector size of 512 bytes and issues 512-byte I/Os, which makes it incompatible with these disks. As a result, the current VHD driver cannot open VHD files on physical 4 KB sector disks. Hyper-V makes it possible to store VHDs on 4 KB disks by implementing a software RMW algorithm in the VHD layer to convert the 512-byte access and update request to the VHD file to corresponding 4 KB accesses and updates."

AI answer.

Thanks for the information! For all, who have to fix their UC.JS scripts, CSS stylesheets and custom buttons, the changes from 68 to 74 are very important. Therefore, it is not "unnecessary junk information". I personally had to fix a lot. Fortunately, I am almost through with that.

@feodor2 Ok. Now, your fix seems to be working. At least, the code editor has started again to behave as usual. The reason it didn't work before was when purging the startup cache, then the code editor becomes inaccessible and a normal restart has additionally to be performed. However, I modified the fix a bit to depend on the current platformVersion instead of a static number. For this purpose, I had to insert one additional line. The code posted beyond is the part from line 1 to 59 of the SelfHelper.jsm file. The changes are located in line 55 and 56: var EXPORTED_SYMBOLS = ["SelfHelper"]; var AC, SelfHelper = { data: { "chrome://custombuttons/content/editor.xul": { 65: "groupbox", 68: "ondialog", 71: "textbox menulisticonic cbeditor", 76: "input", 77: "menulist", 85: "fluent", 108: "contentbox", 109: "menulist109", 113: "flexapocalypse", 116: "wrapwidth", 125: "picker" }, "chrome://custombuttons/content/prefs.xul": { 65: "groupbox", 68: "ondialog", 107: "checkbox", 111: "dialogwidth", 113: "flexapocalypse" }, "chrome://custombuttons/content/dialogs/finddialog.xul": { 65: "groupbox", 68: "ondialog", 71: "textbox", 76: "input", 107: "checkbox", 111: "dialogwidth", 113: "flexapocalypse" }, "chrome://custombuttons/content/dialogs/cbpromptdialog.xul?type=checkbox": { 65: "groupbox", 68: "ondialog" }, "chrome://custombuttons/content/dialogs/cbpromptdialog.xul?type=radiobox": { 65: "groupbox", 68: "ondialog" }, "chrome://custombuttons/content/dialogs/replconfirm.xul": { 68: "ondialog", 111: "dialogwidth" }, }, noop() {}, get map() { var {AppConstants} = AC || ChromeUtils.import( "resource://gre/modules/AppConstants.jsm" ); var {platform} = AppConstants; this.platform = ["win", "linux", "macosx"] .includes(platform) ? platform : "linux"; var { Services } = ChromeUtils.import("resource://gre/modules/Services.jsm"); this.version = parseInt(Services.appinfo.platformVersion); if (this.version >= 95) { var pref = "extensions.custombuttons.prefersColorSchemeOverride"; var pb = Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefBranch); Thanks for the temporary fix! I hope you can fix your browser in terms of the versions problem soon.

Once again, this is the new code from line 1 to 58: var EXPORTED_SYMBOLS = ["SelfHelper"]; var AC, SelfHelper = { data: { "chrome://custombuttons/content/editor.xul": { 65: "groupbox", 68: "ondialog", 71: "textbox menulisticonic cbeditor", 76: "input", 77: "menulist", 85: "fluent", 108: "contentbox", 109: "menulist109", 113: "flexapocalypse", 116: "wrapwidth", 125: "picker" }, "chrome://custombuttons/content/prefs.xul": { 65: "groupbox", 68: "ondialog", 107: "checkbox", 111: "dialogwidth", 113: "flexapocalypse" }, "chrome://custombuttons/content/dialogs/finddialog.xul": { 65: "groupbox", 68: "ondialog", 71: "textbox", 76: "input", 107: "checkbox", 111: "dialogwidth", 113: "flexapocalypse" }, "chrome://custombuttons/content/dialogs/cbpromptdialog.xul?type=checkbox": { 65: "groupbox", 68: "ondialog" }, "chrome://custombuttons/content/dialogs/cbpromptdialog.xul?type=radiobox": { 65: "groupbox", 68: "ondialog" }, "chrome://custombuttons/content/dialogs/replconfirm.xul": { 68: "ondialog", 111: "dialogwidth" }, }, noop() {}, get map() { var {AppConstants} = AC || ChromeUtils.import( "resource://gre/modules/AppConstants.jsm" ); var {platform} = AppConstants; this.platform = ["win", "linux", "macosx"] .includes(platform) ? platform : "linux"; this.version = 74; if (this.version >= 95) { var pref = "extensions.custombuttons.prefersColorSchemeOverride"; var pb = Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefBranch); Is that correct? You should think carefully about what you say. None of what I have written is spam or flame. Do you even know what spam or flame means or is? However, your statement I quoted above comes closer to that. Politeness doesn't seem to be everyone's cup of tea. Anyway! Can you finally explain why the Custom Buttons extension properly works in Firefox 74 without any fix but not in Mypal 68.14.8b? Just a wrong version number which your browser reports to the Custom Buttons extension at a certain point as I assumed at the beginning?

So here I give more information. I did same path as firefox did, and put 74 version because this is where I stopped of clean of xul, yes not all xull stuff has been removed, this essential about interfere new functions, remember wrong icons on permissions. Also you may want to learn yourself what and when removed between 68-74. For everybody else this is unnecessary junk information waste to discuss.

@AstroSkipper may be you missed something, do it again carefully and do not forget about purgecaches If any other fellow use custumbuttons too please confirm. I say again that other your written page is irrelevant, also I thing this is unnecessary information here for others too, so may considered as spam or flame whatever.

I tried your fix. If I have understood you correctly, in the SelfHelper.jsm file, I should replace line 55 this.version = parseInt(AppConstants.MOZ_APP_VERSION); with the following one: this.version = 74; If so, then this does not fix anything. The only thing that happens is a lot of new ReferenceError messages "Service is not defined" in the Browser Console. Furthermore, I think that it is not the Custom Buttons extension that needs to be fixed, which runs properly under Firefox 74, but Mypal 68.14.8b. What do you mean by "hubbub"? Did you even read what I wrote? I consider such an answer to all my information, investigations and questions that I have put a lot of effort into to be absolutely inadequate. I have asked you a few questions, but have not received any answers. And once again, I no longer think the issue is related to a version mismatch. All is explained in the posts above and in my thread "Mypal 68 in Windows XP". Keyword: XBL But I will not repeat myself here.

This hubbub is all irrelevant. Nevertheless one place checks MOZ_APP_VERSION So you can fix this diff --git a/chrome/custombuttons/content/SelfHelper/SelfHelper.jsm b/chrome/custombuttons/content/SelfHelper/SelfHelper.jsm index 8e009ac..42807e7 100644 --- a/chrome/custombuttons/content/SelfHelper/SelfHelper.jsm +++ b/chrome/custombuttons/content/SelfHelper/SelfHelper.jsm @@ -52,7 +52,7 @@ var AC, SelfHelper = { this.platform = ["win", "linux", "macosx"] .includes(platform) ? platform : "linux"; - this.version = parseInt(AppConstants.MOZ_APP_VERSION); + this.version = 74; if (this.version >= 95) { var pref = "extensions.custombuttons.prefersColorSchemeOverride"; var pb = Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefBranch); I shall think out what to do with the version discord.

@feodor2 I'm afraid that you've overshot the mark with your changes as you did in version 68.14.5b. With a probability bordering on certainty, there will be other "patients" who suffer from similar "symptoms" as is currently the case with Custom Buttons. Whatever the actual cause, I hope I could help you with my investigations and information.

@feodor2 Although Mozilla does and has done things to their Firefox browser for years that I personally think are terrible, certain features, even if they are considered deprecated and not secure, will be retained for compatibility reasons. That's something positive. On the subject of XBL and binding, what about the CSS property -moz-binding in your new release? This property is also used by Custom Buttons. For example, for the code editor in the file codeeditor-cbeditor.css: cbeditor { -moz-binding: url(chrome://custombuttons/content/cbeditor.xml#custombuttons-codeeditor); } #accelkey { -moz-binding: url(chrome://custombuttons/content/cbeditor.xml#accelkeytextboxbinding); } Can Mypal 68.14.8b even cope with this?

Thanks for your reply! I investigated the code of Custom Buttons more deeply, and you are right, the Custom Buttons extension solely relies on the platformVersion, Since you removed the XUL stuff, you logically can't keep the platformVersion at 68. But your new release Mypal 68.14.8b has become somehow versionless. It doesn't behave as a Firefox 68 and it doesn't behave as a Firefox 74. It's a bit lost. Your browser tells Custom Buttons that it is Firefox 74, but it is not. Today, for this purpose, I have made a proof and installed Firefox 74 Portable on a Windows 7 Professional 64-Bit notebook, injected the two files config-prefs.js and config.js, and installed the legacy Custom Buttons extension. As I have already predicted, Custom Buttons runs perfectly under Firefox 74. The code editor is fully functional. The legacy Custom Buttons extension has always been compatible with much newer Firefox versions and is constantly being developed further. Here are two screenshots to demonstrate what the issue is about: Custom Buttons' broken code editor in Mypal 68.14.8b: Custom Buttons' fully functional code editor in Firefox 74.0.1: As I already said, you must have removed something that Mozilla did not. And I suspect it has something to do with XBL. Certain functions for binding XML files are required by the Custom Buttons extension for the code editor, which you have probably removed. That's why I said your new release is somehow versionless. Neither fish nor fowl. Sorry for that! The conversion from XUL to XHTML is no problem as you can see. Anyway! I hope you won't behave worse than Mozilla did in the past, and I urgently hope you will be able to restore a general version compatibility. And it doesn't matter which Firefox version you raise the platformVersion to as nevertheless the Custom Buttons extension should work then.

>Why doesn't Windows 98 work with a multi-core CPU? Because precisely Windows 98 apeared too early to get this feature and in its descendant (ME) the creator of both systems refused to add this feature in favor of NT line OSes.

Custumbuttons rely on the platformVersion, if the value was left 68 it thinks that the xul is preset therefore fails, thats why I lift platformVersion to 74. But it rely not only the version, but other things which is silly I thing, I am to investigate further.

The GPU is the chip on the card, not the video card itself. Each video card is a bus-master device so each GPU can directly access main memory while running its own code, just like the CPU. Each display driver gets a slice of CPU time to refill the GPU instruction and data pipelines so it can keep running concurrent to other GPUs and the CPU. Later NT versions have the equivalent of drivers for each CPU/core/hyperthread built into the OS. Windows 9x and earlier do not so can only make use of one CPU core. ATI didn't fully overcome the one-core CPU bottleneck--the display drivers still use it. But by creating powerful multiple GPU/core subsystems with lots of private, higher performance RAM, they were able to off-load most of the complex graphics rendering from the single, shared CPU.

Moving a folder tree on the same volume should retain creation and modification dates. Moving to another volume is a copy/delete operation and the OS will give all items new creation dates. This could be post-processed by modifying the directory entries with low-level calls. Otherwise the system date and time would need to be temporarily changed as each item is moved.

4.62 on 98 is the only combo I currently have. I recall having the same issue with 9 and 16 on 98se. I've downloaded some earlier versions (along with the source) and will test them on 98.

In comparison to Mypal 68.14.8b, I have executed the two JavaScript commands again in Mypal 68.14.7b: JavaScript commands: parseInt(Services.appinfo.platformVersion); Output: 68 parseInt(Services.appinfo.version); Output: 68 In any case, there is a clear version specification in the previous release.

Sorry but unfortunately, I have to disagree when it comes to Windows XP -> Windows NT 5.1 and Mypal 68. As you know, this topic here is about Mypal 68 in Windows XP . I have tested all possible Firefox version numbers by a SSUAO in Mypal 68.14.8b, and 128 was definitely the minimum to get rid of the yellow message box. Any version lower than 128 failed. Greetings, AstroSkipper

... Respectfully, I beg to disagree ... While 128 is the currently supported Firefox ESR version, the previous ESR (Firefox 115) is also supported, for the sake of Win7/8/8.1 users (support will end, supposedly, next September); the minimum Fx version supported by AMO, is, thus, 115 ... FirefoxESR-115 has the same User Agent String as the release channel Fx-115 had, which was (e.g., on Win7 SP1 32-bit): Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 For Firefox versions 110-119, the "rv:" value was frozen to 109, due to a Mozilla bug ... Below is r3dfoxESR-115.13.0 (a FirefoxESR-115 fork that is able to run under Vista SP2) with a SSUAO of: general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 visiting https://addons.mozilla.org/de/firefox/addon/traduzir-paginas-web/ : When the above SSUAO is "lowered" to Fx-114, general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/114.0 ... the issue you reported occurs: So, probably until the end of Sep 2025, Firefox 115 is now the minimum... Kindest regards.

I would like to find a program that graphically shows the space occupied by the starting sector, the FAT table, the copy of this with the reserved sectors and the location of the data area. With file defragmers I can see the area occupied by the MFT in NTFS, but there is no information about FAT. Do you know any program that shows this data graphically specifying the size they occupy and in what sectors are they? Edit: I'd also find a program that compiles a columnar list indicating the contents of the physical sectors helpful. For example: Sector 0 --> Boot Sector Sector 1-63 --> Empty Sector 64-2048 --> FAT Table Sector 2048-4000 --> Copy FAT Table I guess showing the fragmented location of each file in a list would be too much...

Sorry, that I have not explained well. I know Windows XP can work as data disk with hard drives with 4K physical sector and logical sector 512E (not for booting). My question is whether Windows XP can work with hard drives with 4K physical sector and also 4KN logical sector. The majority of hard drives that exceed the 2 TIB are 4K-512E, but some are 4K-4KN which would supposedly imply breaking the 2 Tib barrier of the Master Boot Record and also of GPT with the Windows 2003 drivers. Does any user have a 4K-4KN hard disk? how to recognize a hard disk before buying.... https://support-en.wd.com/app/answers/detailweb/a_id/20968/

maybe it is time that someone look the published codes from microsoft for example the WRK so we could tell why i had left open my fault saying 4 times 512 = 4 k, but that isnt right - it is 8 times however only cixert fixed that one up if FAT32ex on xp can acseed that 2 TB limit and set a sector size, it might be possible if not its not hard to write a loop that actually parse 512 bytes 8 times on the other hand it would raise question to that classical saying "32 bit are limited to 4 gb" according to this logic 32 bit cant address a HDD bigger then 4 gb the overlappend structure just use two dwords (aka 32 bit * 2 = 64 bits) if i continue to talk like this i can only make speculations but lets say it would be able to pass the size of a dword it would not mean that it can pass the 512 sector as we know it can make 512 sectors with 4 gb (aka 2 tb data) but such things you can read out of the microsoft code/either disassembled/debugged or the published code - it is certainly some work - if someone actually know what the problem is it would be faster then just gambling around i actually wrote data to the disc on i/o level but that memory is far to old to get it back, it actually lack like the most part of it, i just remember a few I/O ports like 1f4 and the writes they are either dword (32 bit) word (16 bit) byte (8 bit) this is not a problem as you just give it a loop to write if you have lets say 1024 bits to write you use for the 32 bit writes (1024/32 = downrounded 33 times) 33 * 32 = 1000 then you still have to write 24 bytes , you can either do this with 8 bit writes or one 16 bit write and one 8 bit write 24 / 16 = 1 after that you have the last byte 8 / 8 = 1 the hardware actually transfer that code into a "next code" this next code dont really care if it was 33 + 1 + 1 writes, it rather finds the data that wants to be progressed to get this information out you need time it took 2 weeks just to compile chrome up another 2 weeks for getting the things around that that makes at least 4 weeks to dig into this - what time i dont have at the moment sorry maybe thats the right spot ? it definatly has low and high parts https://wiki.osdev.org/ATA_PIO_Mode#Registers quote: ";ATA PI0 33bit singletasking disk read function (up to 64K sectors, using 48bit mode)" quote2: "Note on the "magic bits" sent to port 0x1f6: Bit 6 (value = 0x40) is the LBA bit. This must be set for either LBA28 or LBA48 transfers." quote3: " An example: Send 0x40 for the "master" or 0x50 for the "slave" to port 0x1F6: outb(0x1F6, 0x40 | (slavebit << 4)) outb (0x1F2, sectorcount high byte) outb (0x1F3, LBA4) outb (0x1F4, LBA5) outb (0x1F5, LBA6) outb (0x1F2, sectorcount low byte) outb (0x1F3, LBA1) outb (0x1F4, LBA2) outb (0x1F5, LBA3) " it is written in assembly to me it seems to have 3 words (word = 16 bit) that address a 48 bit offset (aka LBA48 / 16+16+16=48 (it seems low, mid and high/LBAlo, LBAmid, and LBAhi) if it is like that it isnt hard either you probaly have to set the right settings and address the 48 bits, its different from the paging mechanism (for ram) what actually has 4k pages, 4 megabyte pages, maybe segments, 64 bit PTE/PDE entrys (that can be done on 32 bit, one example is that CMPXCHG8B command in 32 bit mode it can set 64 bit at once (atomic) ) another atmoic way to store 64 bit in 32 bit mode would would be to use the FPU unit the FPU unit can store 64 bits in an offset - to do so you could just put the two 32 bit values to an offset and storing those on the FPU , from the FPU you then store that value to the requied offset (aka where the PTE´s and PDE´s are at), in short talk you can use the FPU as integer if you do it rightm or even "just as memory storage for more then 32 bit" to make it via fpu unit FST / FSTP would be an example the opcodes (these are the ones who have a memory location, could be used) DD /2 (FST), or DD / 3 (FSTP) can write 64 bits to an offset: https://tizee.github.io/x86_ref_book_web/instruction/fst_fstp.html cmpxchg8b: https://www.felixcloutier.com/x86/cmpxchg8b:cmpxchg8b but jumping around from one project to a other just kills not only 1 project it kills both of projects, you guys are on the point

Hi, I'm wondering why DOS-based systems, especially Windows 98, can't use more than one CPU core or thread at a time. I know it's due to limitations in the DOS-based kernel, but the issue doesn't end when I find out there was a dual GPU, which was fully optimized for Windows 98 and Me (on NT-based systems like XP, it was only detected as one), which was the ATI Rage Fury Maxx. From what I've seen in videos and screenshots of this dual GPU, you can see two display drivers listed in the Device Manager, as is the case with more modern dual GPUs like the GeForce Titan, the GTX 590, or the 690. How did ATI overcome this limitation?

Here are some facts about versions inside Mypal 68.14.8b: JavaScript commands: parseInt(Services.appinfo.platformVersion); Output: 74 parseInt(Services.appinfo.version); Output: 68 ------------------------------------------ Some preferences in about:config: browser.migration.version: 94 extensions.lastAppVersion: 68.14.8 ------------------------------------------ General user agent: Mozilla/5.0 (Windows NT 5.1; rv:88.0) Gecko/20100101 Firefox/88.0 Mypal/68.14.8 68, 74, 88, 94 Neither fish nor meat (German saying). Or, neither fish nor fowl. The problem with this is that there have been some significant changes in the Firefox versions from 69 to 72. If an extension receives the wrong Firefox version at a certain point, this can of course lead to malfunctions. And that's exactly what I think might be the case with the Custom Buttons extension. The other theory, that something elementary has been removed, of course remains. Strangely enough, a few typical error messages relating to the cbeditor.xml file have completely disappeared. Maybe, this file can't be correctly processed now. Possibly due to @feodor2's remove of XBL?