Leaderboard

Work continues on the Vista extended kernel. With the next release, you will be able to spoof version numbers on-demand, for either a specific application or the entire system. The values will be set in osver.ini in the Windows folder. Because I had difficulty accessing high-performance, Vista-compatible hardware for the past few months, I was initially forced to test it on NT4.

Have you guys been following the discussion (I use the term generously) regarding Tobin's demand that @feodor2 remove his contributions at @feodor2's repo? Sparks are definitely flying there (172 posts as of now), though unfortunately the situation as such is as far from a reasonable solution as ever. Among other things, as could be expected, MSFN members and XP fans in general are once again getting portrayed as incorrigible criminals, etc. etc. by you know who. Fortunately for me I'm not on Github, so it's easier to resist the urge to get into it with Tobin and Co., because I'm afraid I could seriously blow my fuse there... Fortunately they have received some fierce opposition as well; I only recognized @dmiranda from here, but there's even a Christian pastor on their case. If you think your nerves can handle it, take a look if you haven't yet. In some sense, maybe I shouldn't urge others to participate there when I won't be doing it myself, but if you have any good ideas, @feodor2 could certainly use them and your support in general. I very much doubt anyone could convince Tobin to come to his senses, though... I sincerely hope @roytam1 remains careful enough not to give them an excuse to do a similar thing to him. Based on the license thread at the repo, I'm not sure if this is still relevant. If it is, I have to say that while I've been doing my private builds based on your Centaury and I'm very grateful for your work, regrettably this is not something I can take on right now... Oh, and welcome @cmccaff1, and thanks for your insights before!

You gave absolutely zero details that would assist anyone in trying to replicate.

The guy who builds the 32-bit XP-compatible versions of MAME has 0.235 available as of yesterday on a Google Drive page here: https://drive.google.com/drive/folders/1eiNztWEpk0C7CiiZXz0SMDM_eJOmb0FO It's just the executable, no other files or folders except "about.txt" I found that link on the Retro Roms forum a year ago: https://www.retroroms.info/forum/topic/32-bit-Mame-and-other-distributions-executables.htm He doesn't archive older versions, but Progetto-Snaps does: https://www.progettosnaps.net/index.php And they put everything inside their downloads, all necessary folders and config files, etc. Although I've tested the newer versions of Arcade in XP, I've stuck with 0.211 because in subsequent versions, the MAME team got rid of the ability to individually enable/disable the various artwork types. Now it's all or nothing. I also like Mameuifx32 version 0.175.1...

Package Details at the Catalog say KB2712808 was replaced by KB3170455, and Package Details for the latter agree.

that means that steam could finally work normally? edit: and make csgo running ?

Yes, and fcwin2k (for specific applications). However, they don't manipulate the GetVersionEx* functions and just manipulate some registry values instead. This was good enough at the time, but isn't 100% effective like my method. And the registry value that win2k used to grab version numbers has been deprecated as of Vista.

I can't say I blame you! I still remember when 0.107 came out, and how stunned I was when I saw games that always ran at full speed with no frameskip starting to have issues...I went back to 0.106 and all of those problems disappeared. I'm glad you're holding onto your backups of 0.106! What's funny is, I stopped following MAME development myself around the time 0.148 came out, so I had no idea that the devs had started using a compiler that broke XP compatibility. I had to get 'up to date' as far as what was going on, and that's how I found out (through Reddit) about 0.204 being the last known version to work properly in XP (at the time). It's wonderful to be able to use a much more recent version now! On my main PC (an old GX620 with a 2.8GHz Pentium D and a 2GB GTX750Ti [which really helps]), 0.106 still flies, and I can also run 0.234 with no problems (as long as you stick to uncomplicated titles [basically, nothing that is too 3D-heavy]). 0.106 (and earlier) are definitely the best MAME versions for computers with 512MB of RAM or less and/or a single core processor. However, 0.67 and earlier might arguably be the best option for ancient (pre-SSE) machines.

updates up to april 2017 + kb4474419 and kb4493730 + updated root certificates just said that a couple of days ago

Just some IT guy had it on his office PC. The main stuff was either on 10 or Server 2016/2019. Not much visual difference between them and I don't always pay attention to whether Server Manager is there or not. It wasn't at IT company, they do things with aluminium actually.

@cmccaff1 Well, i actually hadn't touched anything after v0.148 until recently. With all the other things to occupy my days, emulation took the back seat by that time... I have v0.106 backed-up, along with the MAMEFX and MAMEplus variants :P I don't remember clearly, but i may have been using mainly Win98SE back then, lol.

@RainyShadow - That's absolutely amazing! A while back I tried to download the newest 32-bit build of MAMEUI available at the time, and got a GetTickCount64 error. I ended up downgrading to 0.204 (which was apparently the last known version to date which didn't trigger that error), and it was working fine. I tried the latest build available from progetto-SNAPS (the 32-bit 0.234 you mentioned) and it is ALSO working fine! No glitches or errors to report--it's truly incredible to be able to use such a recent MAME version in XP, and even more incredible that it apparently doesn't require SSE2 (as evidenced by it working on your Athlon XP). Apparently a 32-bit build of 0.235 is now in the works...I'll definitely be testing it once it's available, as I'm sure you will too. I'm not sure if you have tried this version, but on a side note the last version of MAME to use the classic rendering engine (before the developers rewrote MAME to use a Direct3D engine, which has remained the standard since then) was 0.106. Feel free to give it a try on your Athlon XP...it should run brilliantly, and if you know where to look (and if you're crafty enough) you can find many variants of 0.106, and even older versions.

Keep us posted. Note that I have uploaded updated rebuilds in the pinned XP 360Chrome thread.

Updated rebuilds. These are still XP skins, it may be a week or two before I can devote the time to create a Win2k "classic gray" skin. https://www.dropbox.com/s/5b3repgs8ck0zeu/360ChromePortable_12.0.1247_rebuild_2.zip https://www.dropbox.com/s/1fk69d5jhc2vwyg/360ChromePortable_13.0.2206_rebuild_4.zip Special thanks as always to @Humming Owl as the hard-coded portions stem from his builds and he also removed a to-do item from my list with the video and copy-paste tooltip conversions. Also duly note that my previous v13 builds had an issue with downloading .csv files from some sites (such as Google Sheets) and that has been resolved in this build. edit - minor update to v13, link updated to newer upload

Looks like the NHS is still very much based on Windows XP. This was spotted at St George's Hospital in London: p.s not my CT Scan, it's the one of an old woman I think

New NewMoon 27 Build! 32bit https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210828-be0dbe88f-xpmod.7z 32bit SSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210828-be0dbe88f-xpmod-sse.7z 32bit noSSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20210828-be0dbe88f-xpmod-ia32.7z 64bit https://o.rthost.win/palemoon/palemoon-27.10.0.win64-git-20210828-be0dbe88f-xpmod.7z source repo: https://github.com/roytam1/palemoon27 repo changes since my last build: - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1185997 - Split referrer tests to avoid intermittent timeouts. r=RyanVM (976fb981a) - Bug 1175736 - Add iframe referrer attribute tests. r=ckerschb, r=baku (f22da1340) - Bug 1184781 - additional referrer tests - redirect. r=christophkerschbaumer (49f1aaea0) - Bug 1186544 - A better test suite for StructuredCloneAlgorithm, r=smaug (d94f76a45) - Bug 1167690 - Part 5: Add tests for plugin audio channel integration; r=baku (26931ea9d) - Bug 1144631 - Make FTP with auth prompts work in e10s. r=billm/dragana (e69f9f5e0) - Bug 1179255 - (fatal) Assertion failure: aRequest == mCancelable, at netwerk/protocol/websocket/WebSocketChannel.cpp:2766, r=mcmanus (e1e3d6799) - Bug 1024056 - Simple ASCII lexical analyzer. r=nfroyd (dc67ec784) (ac77268e0) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1189369, part 1 - Remove trailing whitespace from some nsNavHistory* files. r=mak (317dd5937) - Bug 1074416 - Don't AddRef or Release nav history result observers during CC traversal. r=smaug (2ce1e8cc6) - Bug 1189369, part 2 - Don't implicitly convert nsMaybeWeakPtr to an nsCOMPtr. r=mak (c4c3261e5) - Bug 1189369, part 3 - Inline nsMaybeWeakPtr_base. r=mak (efdb4fd76) - Bug 1189369, part 4 - Get rid of some old style QIs from nsMaybeWeakPtrArray. r=mak (fa534f76c) - Bug 1189369, part 5 - Use the nice cycle collector macro template for nsNavHistoryResult. r=mak (f1fafbdc9) - Bug 1189369, part 6 - Inline AppendWeakElement and RemoveWeakElement. r=mak (514efe9f8) - Bug 1189369, part 7 - Use nicer nsTArray functions in nsMaybeWeakPtrArray. r=mak (38384b1a1) - Bug 1189369, part 8 - Clean up some minor style issues in nsMaybeWeakPtr.h. r=mak (3f37712f9) - Bug 1189369, part 9 - Use early return in nsMaybeWeakPtr<T>::GetValue(). r=mak (5606a69c5) - Bug 1180498 - Tolerate a different major libGL.so on NetBSD as well r=jgilbert (4f7c00f01) - pointer style (44d4789bd) - Bug 1182428 - Refactor bytecode compilation r=luke (790c13aa2) - Bug 1163851 - Pass the correct |InHandling| argument when parsing the initializer in a LexicalDeclaration in a for-in loop. r=efaust (e6b891d53) - reapply Bug 1163851 - Remove the remaining two tests of |pc->parsingForInit| (c59d57225) - Bug 1180498 - Tolerate a different major libGL.so on NetBSD as well r=jgilbert (9463d2aea) - Bug 1189282 - Refactor parser BindData class r=efaust (4dd897771) - Bug 1179063 - Hook up the static scope chain in the Parser and replace SharedContext walking with scope walking. (r=efaust) (70b8fdd1e) (5cdc3234f) - import changes from `dev' branch of rmottola/Arctic-Fox: - Bug 1186724 - Make BytecodeEmitter::emit2 take a uint8_t instead of a jsbtyecode; r=arai (0520b800d) - Bug 1179063 - Simplify enclosingStaticScope and rename to innermostStaticScope in BCE. (r=efaust) (9b80db494) - Bug 1179063 - Cleanup: remove useless pn_index. (r=me) (8c0599c32) - Bug 1155618 - Fix some more places we don't report OOM properly r=jandem (4c45f314a) - Bug 1165486 - Debug function to dump static scope chain of scripts. (r=efaust) (3de10d2bf) - Bug 1191177 - Kill UpvarCookie. (r=efaust) (373fe90f3) - Bug 1191177 - Kill staticLevel. (r=efaust) (a8734595e) (be0dbe88f)

If consider playing video in the browser, then the fastest way is with plugins. However, this method involves many settings.

MAMEUI claims support for XP - current version 0.234 I tried the 32 bit build from here and after a few minutes of waiting, it started I can even try to emulate an AthlonXP system on my AthlonXP system, lol https://i.imgur.com/QCA5K7v.png [edit] The 32 bit build of MESSUI v0.234 works as well. It even started in less than a minute, yay!