Ascii2

Yes. I was getting rather tired when I wrote that and the post to you and did not proofread the post well enough. I had originally started writing around that quoted question, but then tried to patch the SP2 HALs myself to check. Something I wanted to ask, but forgot, is: Whether it is important for you to stay on an old Windows XP Service Pack 2 level kernel? If not, you might try a newer kernel version (and other possibly other updates).

My impression is that there might be HAL issues or CPU errata/microcode issues on at least the SandyBridge machines. I have tested the WinXPPAE.exe 3.5.0.0 patch tool on newer HAL files than the initial Service Pack 2 version, and they are also rejected as invalid by the patcher. Perhaps the SP2 versions do not need the patch; it is possible that whatever is patched for the Service Pack 3 HALs might not be an issue on the SP2 HALs. Have you tried using the SP2 HAL with the WinXPPAE.exe 3.5.0.0 patch tool patched SP2 kernel? Regardless, you might wish to try newer SP2 HAL. The update packages that I have are all intended as the English language (United States) versions, however, I would expect the HALs should still work in another language distribution if the HAL file is specified explicitly in boot.ini. I have uploaded the HAL updates for English Windows XP with Service Pack 2 to: https://www.mediafire.com/file/5ibjk0jsnltisxa/SP2_HAL_Updates.zip/file File Name: SP2_HAL_Updates.zip Size: 7,597,675 bytes CRC32: BA5633F7 MD5: 170844F1EDE2CE551C9E5F213A283059 SHA-1: E29ADE7FE24B8C7D10CDCF1EB30D197733B57DFA SHA-256: B911093A86B272BFDADCEF9F27335DD6E677E0DE60E4D00BBFEFD83C3AC3AB54 SHA-512: E7F08887D5E1DC432C269A40CD5E977F2806FF9D14DDFBBE86B6C58BFB519A3D738F9E98665F3D110619D314A8D6E6385BED5C5520CD97559A7058F62DB55A68

Yes, the batch script is rather defective in that it is unreasonably presumptive as to where resources or files are and can result in not finding the something it should find, finding the wrong thing (which can become a data corruption problem after write operations are performed on originals, such as boot.ini), presuming one wants to use kernel or HAL from sp3.cab, etc. However, the script does provide some level of instruction of a potential method to patch files and deploy those patched files.

Yes, with the daniel_k's solution, he is not providing a pre-patched binary of a single kernel variant version and a single HAL variant version like that "other" patch you referenced; rather, he provides a patcher that can be used on any compatible variant or HAL and any version of such. The daniel_k's solution is generally better and provides more compatibility options. I would disagree. Older PCs could have relatively large amounts of RAM. It is also important to note that it is not RAM that needs to be considered, but addressable memory (which is inclusive of RAM and other things like allocations for video card memory). A old PC system utilizing only 4 GB of RAM would still likely benefit from the PAE fix patch. Even then, there were computers with much larger amounts or RAM and addressable memory; these were often rather expensive at the time. It is also best to think of the patch as a PAE (Physical Address Extension) fix patch rather than a RAM patch; the intentions and products are different. It also seems like there is a presumption that multi-core processors must use a Muti-processor HAL; however, that presumption would not be correct. Multi-core processor can still use Uniprocessor HAL. It is a configuration I often use (one may also often take the opportunity to scale a single core well beyond where it would tend to scale in a multi-core conflagration while having the other cores turned off). Many CPU architectures since about 13 years ago have had this capability and design consideration. The daniel_k patcher provides a patch tool, while "other" patch you linked to is someone's product of patching and in a limited case.

I am not doubting that you have been able to the a PAE kernel to load. The /PAE switch appears to modify the bootloader configuration behavior towards selection to PAE, but does not override explicitly specification the kernel and HAL. Yes, there are various criteria that is evaluated to determine what the bootloader would load, but the criteria should not usually override explicit and compatible specification. With regards to your sources for the DEP default handling behavior, it is my impression that the evaluation mechanism is against hardware provided DEP (which is often an option on BIOS that is reasonably configurable). Where hardware DEP is detectable by the bootloader (perhaps because BIOS has the feature disabled), I do not believe the bootloader selection behavior would necessarily tend towards selection of a PAE kernel. I have never tested that, however. With regards to Windows XP with Service Pack 2 HAL updates, I have compiled a list of fixes that I think should be useful to you: For Windows XP Professioal with Service Pack 2 Install in ascending order: HAL updates (all in ascending order): KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2 KB896256 - Computers that are running Windows XP Service Pack 2 and that are equipped with multiple processors that support processor power management features may experience decreased performance KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation KB951126 - A multiprocessor computer that is running Windows XP stops responding on a black screen after you resume the computer from hibernation KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer Only need, to fully update: KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2 KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer Other Fixes of interest despite not being HAL: KB952117 - When you try to put a Windows XP-based computer into hibernation or into standby, the computer stops responding

What is rather apparent is that you are using the initial kernel and HAL releases, where compatible with the daniel_k HAL/NTKernel v3.5 patcher. Especially for Windows XP with Service Pack 2, it is important to use newer HALs than were initially released for newer hardware during that time period (which would now be considered older hardware). The systems could have rather annoying bugs otherwise. Your computer, given the hardware, is such a case. A newer kernel would be better, unless there is an important reason that you must stay with the older version. HAL updates were only distrusted as (downloadable) hotfixes; whereas, kernel updates were both in regular updates and hotfixes. With regards to not having to use the /PAE switch because "noexecute=optin is enough". That is not correct. The reason why you might find that the /PAE switch need not be specified for PAE in your case is because you are explicitly specifying and overriding the kernel and HAL to use ("/kernel=" and "/hal=") rather than relying on the otherwise default (potentially "/PAE"-influanced) selection. (See https://web.archive.org/web/20061224201614/http://www.microsoft.com/technet/sysinternals/information/bootini.mspx for a reference on the various arguments you may use in boot.ini.) You also still have not specified the variants/flavors of the kernels and HALs used. Make sure that you have correctly matched the HAL and kernel.

I notice a few things: It is my understanding that Windows XP with Service Pack 2 is used here (which presumably also using Service Pack 2 HAL and kernel). The patch author appears to have tested against Windows XP Professional with Service Pack 3 but not Windows XP Professional with Service Pack 2. reboot12 has not indicated which kernel and HAL file versions (both version number and variant/flavor of HAL or kernel) he has patched and tested. It would be also good to specific the relevant boot.ini configuration used. The problems experienced might not be due to defective patch but rather other bugs or defects in the patched files or elsewhere (such as other system files or other software). The videos do not demonstrate a problem with disk operations but rather performance of select operations.

It is my understanding (I do not renumber why so; it may be hearsay) that the latest patcher, v3.5, includes a process RAM allocation limit; whereas, older versions (so sure how much older) did not. I am unsure of the reasoning why (but do have best guess) and I do not remember if such is consistent with the Windows XP (any flavor) with Service Pack 1 behavior. EDIT: Also, perhaps about 20 years ago, I knew rather better how PAE funcntions. It is my impression that while PAE does allow to more RAM usage (and against a virtual addressing resource penalty), there are still limits and individual processes might not be able to utilize more than a particular amount. I think for 64-bit Windows those limits are much (much) higher. The daniel_k HAL/NTKernel patcher seems to try to restore a more true PAE behavior. It would have been nice if the daniel_k HAL/NTKernel v3.5 patcher would have come with instructions and a changelog.

I notice now with the Project VORAPIS V3 0.9.0.8 and V3 0.9.0.7 extensions ( https://vorapis.pages.dev/ ) on MyPal68 68.14.8b on Windows XP Professional with Service Pack 3, YouTube can no longer play videos. I receive the below representation in the video space instead of the display of the actual video: https://ibb.co/fYXBhs9D My YouTube HTML5 Video Player page looks like: https://ibb.co/r8H7vqr EDIT: Apparently, codecs from local system might not have been recognized by myPal68 at the time before. After installing some codecs to the local system that were not installed before, the YouTube videos with Project VORAPIS (now also with Project VORAPIS updated to version 0.9.0.10) play, though with higher resource usage than I was accustomed to months ago when the Project VORAPIS YouTube also worked.

As I had referenced at https://msfn.org/board/topic/185966-my-browser-builds-part-5/?do=findComment&comment=1268699 , please provide the changes information between what roytam1 used as a base for his derivatives of the Binary Outcast applications and the Retired XUL Platform (RXP). Also, from what you posted recently and other times, I would recommend/warn/counsel/advise the following to you and others generally: At times, there is much bad by others that may be done against one (there are many reasons why such may happen) and one may desire and hope for particular things. It is important to not forsake such things and try to do what is correct. However, it is notably important not become prideful; wrathful (unreasonably or persisting in anger or vengeance), or envious, or lustful, in the process or otherwise, even against malevolence, as it is bad for the self and mind. It might be difficult at times, when in the momentum of such, but one should examine or rest and examine things clearly. Further, if one does not, one also may have tendency to engage in that which is unjust or unrighteous, and one might also become a similarly undesirable variant of what one was originally against. It is important to truly rest both physically and in terms of one's pursuits; it is helpful in achieving clarity. Even if the rest of the world becomes fallen, one need not and should not fall with it. One may wish to even prevent the world from falling; however, it is important to note that one does not have the resources or time (both in terms of mortality and opportunity cost) to do so oneself, and most likely will not without falling oneself. Should you heed this advise, things should improve for yourself (and potentially and consequently also for others).

@user57, that was also my conclusion, if I understood your post correctly. For the moment, your v3.4.6 release seems to be working well enough. I shall continue to use that for now. Thank you for your efforts.

Hello @Elkern 4926 Tobin. Thank you for making an appearance. I had noticed that you had a new(ish) GitHub repository with the Binary Outcast software, for which you referred to it as "Retired XUL Platform (RXP)", and that is different than than one @roytam1 had based his forks of the Binary Outcast software against. It appears that you had at least un-suppressed the Go and Search buttons (which makes using the functionality with mouse easier and reasonable). @roytam1 had examined the commits listing of the Retired XUL Platform (RXP) repository and did not find much. It would appear that the differences between what roytam1 based and the Retired XUL Platform (RXP) version does not have an obvious indication of the changes without examining everything directly. Please provide the changes information between what roytam1 used as a base and the Retired XUL Platform (RXP). For context of this issue, please examine the following posting information. They are in ascending order:

@user57, thank you for the quick attention to the matter. I was able to find other computers to test on. They were running Windows 10 Pro. With regards to the issue with dragging and dropping files into a window with an already open document, the problem does manifest with both the original and your releases of SumartraPDF 3.5.2. With regards to the GUI issue, neither your nor the original author release manifest the problem on Windows 10 Pro.

After testing on Windows XP Professional with Service Pack 3, I note the following problems: 1. Dragging and dropping to open files does not work when there is already a document open. Prerequisite: Use standard window mode (which also disables tabs). Problem Description: Drag and Drop to open document does not work when there already is an open document. Regular menu system to open document still works. Expected behavior: After dragging and dropping next document to open into window with already open document, another window should open with the dragged-in document. What actually happens: Open window becomes inactive and no new window with the dragged in document is shown. However, there is a new SumatraPDF.exe process created without a visible window and without the ability to terminate the process not forcibly. 2. Visual GUI display bugs. Toollbar items display is somewhat, wrong-looking. This is what it looks like: [COULD NOT UPLOAD IT]

Yes, it did appear that Tobin did not want the buttons initially (my guess is that he did not like that the buttons had a late 1980s or early 1990s appearance). However, it appears that Tobin's new repository includes the buttons and presumably with a new, more modern appearance as seen in his provided browser window picture. Regardless, I would propose that the browser is better with the buttons. The buttons are especially useful when the hand that is not on the mouse is busy (holding paper, telephone etc.) or when a keyboard is not available (or covered with papers). The buttons being omitted also results, cosmetically, as if the URL browsing functionality or interface is incomplete. Hopefully @roytam1 would provide the buttons.