Leaderboard

Today I notice the ads are gone... since I know money has been tight on the forum and I cant personally donate I'm a bit concerned that the forum wont get enough revenue if they stay broken. What's happening with them?

I've changed my mind. I'm going to keep it up. Y'all have inspired me to not give up. So, XP x64 will remain my main OS for a long time; I can still squeeze more life into it.

Hello everyone, this time I do not bring a question if not a solution for all users who are still using Windows Vista in 2019, how to install new versions of the .NET Framework in Windows Vista! Tested versions for me: 4.6.2 | 4.7 Requirements to be able to update net framework in Vista to more recent versions: Service Pack 2 installed (I recommend having the platform supplement and all the updates until April 2017) Net Framework 4.6.1 (Latest version compatible tested until moment with Vista) Compressor files like WinRAR or 7zip Warning: You will not be able to use Windows Update again in Vista after installing NET Framework 4.6.2 or 4.7.2, I recommend updating the system with all the updates until April 2017! Let's start with the procedure: Download the net framework version chosen in this case 4.7.2 from the MS page With our file compressor open the executable to install net framework and look for the file ParameterInfo.xml and copy it to the desktop Open the xml and search this line: <BlockIf DisplayText="#(loc.Blocker_UnSupportedOS)" ID="UnSupportedOS"> Replace all this code: <BlockIf DisplayText="#(loc.Blocker_UnSupportedOS)" ID="UnSupportedOS"> <And> <Equals LeftHandSide="Installing" BoolWhenNonExistent="false"> <Operation /> </Equals> <Or> <Or> <GreaterThanOrEqualTo LeftHandSide="6.1.0" BoolWhenNonExistent="false"> <TargetOS /> </GreaterThanOrEqualTo> <And> <Equals LeftHandSide="6.2" BoolWhenNonExistent="false"> <TargetOS /> </Equals> <Equals LeftHandSide="Client" BoolWhenNonExistent="false" Id="IsClient"> <RegKeyValue Location="HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallationType" /> </Equals> </And> </Or> <And> <Equals LeftHandSide="10.0" BoolWhenNonExistent="false"> <TargetOS /> </Equals> <GreaterThan LeftHandSide="14393" BoolWhenNonExistent="false"> <RegKeyValue Location="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber" /> </GreaterThan> </And> </Or> </And> </BlockIf> For this other code: <BlockIf DisplayText="#(loc.Blocker_UnSupportedOS)" ID="UnSupportedOS"> <And> <Equals LeftHandSide="Installing" BoolWhenNonExistent="false"> <Operation /> </Equals> <Or> <Or> <GreaterThan LeftHandSide="6.0.0" BoolWhenNonExistent="false"> <TargetOS /> </GreaterThan> <Equals LeftHandSide="6.1.0" BoolWhenNonExistent="false"> <TargetOS /> </Equals> </Or> <And> <And Id="Is2k8ServerCore"> <And> <And> <And> <LessThanOrEqualTo LeftHandSide="6.0.0" BoolWhenNonExistent="false"> <TargetOS /> </LessThanOrEqualTo> <GreaterThan LeftHandSide="6.1.0" BoolWhenNonExistent="false"> <TargetOS /> </GreaterThan> </And> <Not> <Equals LeftHandSide="Client" BoolWhenNonExistent="false"> <TargetOSType /> </Equals> </Not> </And> <Exists> <FileVersion Location="%windir%\system32\oclist.exe" /> </Exists> </And> <Exists> <Path Location="%windir%\system32\scregedit.wsf" /> </Exists> </And> <Not> <LessThanOrEqualTo LeftHandSide="4.0.31106.0" BoolWhenNonExistent="false"> <FileVersion Location="%windir%\System32\mscoree.dll" /> </LessThanOrEqualTo> </Not> </And> </Or> </And> </BlockIf> After saving the file open the net framework executable Open the label that you have installed Vista in this case C and you should find a folder with a long name that includes hexadecimal characters, open it and quickly replace the XML ParameterInfo that you edited. Note: I may still show you that it is not compatible, this is tedious and annoying but try several times as fast as possible to replace the xml ParamenterInfo while the files are being extracted before the installation begins! Net framework updated in Windows Vista! Screenshots here: https://drive.google.com/open?id=14gKJ6JlY1XxeDvcZtS7WdfncfnbHRAnZ https://drive.google.com/open?id=1r8bmcCjJ30UewCxCXgraMKunbhrk9ynb https://drive.google.com/open?id=1gdvPTKUbvEMPCBK2u-Osfxk-Fnttl3as

Hi, im happy to report that the new may monthly rollup preview did fix the vmware issue. I mean the new preview (23rd of may). But i recommend to everyone to just stick with virtual box. Vmware keeps crashing and it is annoying though it no longer crash the os. I still can't use banking site on my laptop, cause i use id card to log in and that would cause vista to crash with win32k nonsense again. i'l keep you updated if anyone changes in future. I still use vista on my main laptop so it is easy for me to tell if new update has broken something or not.

For those who want to check the status of port 3389: https://www.yougetsignal.com/tools/open-ports/

Hey! Good to see you around, @submix8c! You have been missed!

Oh sorry i didn't notice. No, i'm not using any antivirus software.I've installed the may udate as soon as it was available, but vmware was still bsoding my machine. For some unknown reason the Preview does seems to fix it (mostly). Maybe someone can try if avast will run again after this patch..

isn't it faster to just open netfx_x64full.exe? I mean is there any benefit doing it this way? Thanks

OK, follow-up : @Tangy: Many thanks indeed for your tests on NM28, St52 and FxESR52; the fact the clip played back fine in these browsers on XP provided additional clues for me (see below...). I am on Windows Vista SP2 32-bit myself, with Platform Update Supplement installed correctly; this means I have a working implementation of Windows Media Foundation (WMF) media framework, which, in layman's terms, means compatible browsers (Firefox and forks) have access to system (OS) decoders for patented formats (h264 for video, aac & heaac for audio); to be more precise, h264 decoding in HTML5 videos is delegated under Vista SP2 to system file mfh264dec.dll (file version on my setup is 7.0.6002.18392, "7" indicates this was a Win7 feature backported via PUS to Vista SP2). In Firefox ESR 52.9.0 under Vista SP2 (with PUS) I don't have to install and enable the Adobe PrimetimeCDM to achieve h264 decoding in HTML5 video (which is the case for WinXP), because the browser, as explained above, has direct access to OS decoders; this works 99% of the time, but, apparently, NOT for this specific video . In Media Source Extensions (MSE) capable browsers, Facebook serves the video via MPEG-DASH streams (fragmented .mp4 files); it is my conviction, after extended testing, that the default system h264 decoder can't cope with this video's unorthodox dimensions (being in "portrait" rather than "landscape" form, 9:16 instead of 16:9). If in FxESR 52.9.x I disable WMF by toggling media.wmf.enabled to false (and with no AP CDM present), then the browser has no way to decode the video stream; fortunately, facebook can still fall back to using the Adobe Flash Player NPAPI plugin (v32.0.0.171) for playback purposes and this does play the clip in question (but in a pop-up, not in-page): The situation is a bit different in the case of the UXP forks; to cater to WinXP users who, as stated, have no access to OS decoders via WMF, @roytam1 has patched the ffvpx library to include (ffmpeg provided) patented decoders for h264/aac; in Vista+, both following prefs are set to true by default: media.wmf.enabled;true media.ffvpx.enabled;true but priority is given to the WMF decoders; that is why I can't play back properly the mentioned video clip in either NM28/St52 (screengrab is with NM28) : If I toggle media.wmf.enabled to false, then h264 decoding is being delegated to the native ffvpx (ffmpeg decoders) implementation and, as things stand, can properly decode the "portrait" video (NM28): And, as expected, if I toggle both cited prefs to false, NM28 will use Flash (in a pop-up): ... Before I classify this as an obscure Vista bug (with no hope of ever getting fixed), I need to know the results of some additional tests: Many thanks for your time spent, especially during "office hours" ; but don't bother testing on WinXP, according to my troubleshooting and @Tangy's feedback, it will certainly work when ffvpx is the decoding module ... When given the chance, can you please re-test with media.ffvpx.enabled;false ? If it plays, then Win10's system decoders can handle OK the 9:16 h264 video stream... Lastly, I need some kind soul to test for me how latest New Moon 28.6.0a1 on Win7 performs on this clip when, again, media.ffvpx.enabled;false and media.wmf.enabled;true ; if it doesn't play, repeat the test with an official Pale Moon binary (ffvpx there doesn't have h264 decoding support); in the small chance the video doesn't play, it's a UXP bug on Win7 (which means it could be reported to the official devs and, down the road, be fixed eventually...); if the clip plays fine with only Win7's system decoders, it's definitive: my case is a fatal Vista bug I'll have to live with Many thanks for the attention and precious time of this forum's fine members PS: As to the mystery why the video plays back fine in NM 27.9.6 on my Vista setup, I think the answer coincides with my findings so far: facebook serves MPEG-DASH, this requires MSE; on Roy's Tycho fork, MSE+h264 decoding is handled by the supplied LAV dlls, not by the system decoder (as proven by a "youtube.com/html5" test without those files...).

Or perhaps they say, "You want patches? Here's a critical patch that breaks your best free antivirus, lol."

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rths.cf/basilisk/basilisk52-g4.2.win32-git-20190525-315ffd563-xpmod.7z Win64 https://o.rths.cf/basilisk/basilisk52-g4.2.win64-git-20190525-315ffd563-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom NM28XP build: Win32 https://o.rths.cf/palemoon/palemoon-28.6.0a1.win32-git-20190525-315ffd563-xpmod.7z Win64 https://o.rths.cf/palemoon/palemoon-28.6.0a1.win64-git-20190525-315ffd563-xpmod.7z Official repo changes since my last build: - Unhook Unboxed Objects option (3ded48cbe) - remove unboxed code chunk (wip1) (9a3141515) - Remove initial chunk of Unboxed Objects machinery part 2 (3b36a43e8) - Remove Unboxed Objects in ScalarReplacement (d40bcc350) - Remove unboxed objects from GC (5fd4b8726) - Remove unboxed object code from iteration. (8feffe707) - Remove array header (a5c2961c4) - Remove Unboxed Objects from vm/ Part 1 + fix deprot (543fa1674) - Remove unboxed object code from jit, Part 1 (fa8bfa1a0) - Remove Unboxed Objects from vm/ - Part 2 (201d8ee48) - Implement array.flat and array.flatMap (162e22a7d) - Implement Symbol.prototype.description (41731a7f3) - Issue #971 - Fix browser.link.open_newwindow functionality in Pale Moon (f9dc4e8cc) - Merge pull request #1097 from FranklinDM/pm_external_sametab-work (a1f96f11d) - Merge pull request #1091 from MoonchildProductions/remove-unboxed (be8d03cf1) - Remove a stubbed telemetry function from app AUS. (bb5e0a1be) - Enable double buffering when using XRENDER. (2fd300786) - Merge pull request #1100 from Ionic/bugfix/xrender-flicker (372fccddf) - Issue #1104 - Set the browser's opener when adding a new tab - This modifies `loadOneTab` and `addTab` to accept an opener - This code was adapted from Basilisk's copy of tabbrowser.xml without the refactored code changes (which is a lot more involved as it divides addTab's functions into multiple functions) (797697e26) - Issue #1104 - Pass an opener to loadOneTab in the openURI function (10318170b) - Issue #1101 - Support gzip-compressed SVGs in OpenType+SVG fonts (73f9b2c70) - Merge pull request #1108 from g4jc/svg_opentype (f8157b8a6) - Merge pull request #1105 from FranklinDM/pm_uri_tabbrowser-work (f0e357608) - Merge pull request #1099 from adeshkp/remove-telemetry-func (315ffd563) My changes since my last build: - ported changes from mozilla upstream: bug1351303, bug1352235, bug1371508, bug1430268, bug1352734

I quote myself to give you a little update. It may look like as if we are doing nothing, but we're not. @someguy25 asked me about Chromium 74 and since I really love Chromium, we re-forked it once again and I tried to backport for the 5th time. Compiling it using v141_xp and targeting XP leads to nowhere as the new SDK does not compile, however commenting out the sandbox and some other parts of the code made it compile, however the code was unusable as 27 calls were missing (including - but not limited to - the kernel). By removing many unnecessary components and taking it to its very bone, I managed to lower the number down and by linking it to the @Dibya modified kernel we managed to get this number even lower. Right now, the only missing calls are QueryThreadCycleTime, SymGetSearchPathW, SymSetSearchPathW, SHGetKnownFolderPath, SetProcessDPIAware, however the SymGetSearch can be delayed and not loaded at start-time and SetProcessDPIAware can be faked to equal true all the time, so the only really meaningful kernel call that has to be implemented and backported is QueryThreadCycleTime, 'cause once we get that and we fake SetProcessDPIAware, we're gonna get Chromium74 open and display the UI, which would be totally positive sign. BOOL QueryThreadCycleTime( HANDLE ThreadHandle, PULONG64 CycleTime ); It refers to the realtimeapiset.h which works on Windows7 and greater only and it has two parameters: ThreadHandle, which has either the PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION access right and CycleTime which is the number of CPU clock cycles used by the thread and it includes cycles spent in both user mode and kernel mode. In order to avoid to try to use it, I tried to convert the Thread32 function and use the elapsed time, however I didn't manage to get positive results as it's important to know the exact clock cycles as it varies between CPUs, for instance some CPUs will vary the frequency of the timer when changing the frequency at which the CPU runs and others will leave it at a fixed rate, so asserting it will almost certainly lead to wrong results (which is what happened in my case). Unfortunately I don't have much time to dedicate at this, nor my "virtual XP colleagues" like Dibya, Samuel and Peter do as we're all very busy for a reason or another and we don't also wanna become blind by staring at "apparently meaningless" lines of code... I'm sorry that my fifth attempt to backport Chromium led to nowhere once again... Good night, Frank...