VistaLover

The Borealis Navigator is built upon the UXP platform (much like Basilisk 52[Serpent 52.9.0] and Pale Moon 28[New Moon 28.x.xa1] browsers; UXP was forked from the Mozilla ESR 52[.6.0] platform; the versions of the Seamonkey suite that build upon Mozilla ESR 52 are of the 2.49.x branch, last one released from that branch was 2.49.4 (built on Mozilla ESR 52.9.0); so, in theory at least, Borealis Navigator 1.0 should be compatible with all Seamonkey 2.49.4 compatible extensions; but there are notable exceptions: the author of BN (infamous Matt A. Tobin ) has disabled support for all jetpack and WebExtensions addons, so that leaves room for only XUL Overlay and Bootstrap extensions (out of the ones compatible with SM 2.49.4); you can read more about BN in its official page: http://binaryoutcast.com/projects/borealis/

Not the New Moon (PM28XP) ones... They point to versions 28.2.0a1, while on the server the appVersion is 28.3.0a1 (which is correct)...

Hello @someguy25 KB2467173 would install v10.0.30319.415 of the redistributable; however, this is not the latest version; KB2565063 is, which installs (hopefully) v10.0.40219.325 ... To install KB2565063, you first have to install Microsoft Visual C++ 2010 SP1 Redistributable Package (x86) (v10.0.40219.1); that one will appear, after having been installed, as a separate entry inside your "Add/Remove Programs" Control Panel section... Just my 2p

I inadvertently found out that Internet Explorer 9 is again, as of late, able to play back youtube videos, so it appears Google (the owner of youtube) have patched their scripts to cater to IE9; this surely comes as a (nice ) surprise, but the reason behind such a move seems inexplicable to me... Perhaps was to support WS 2008 SP2 (officially supported until Jan 2020), on which IE9 is the only version of the native Microsoft browser to run, but I'm not convinced... For whatever reason, youtube now has been restored to its previous state in IE9, serving standalone MP4 encodes over HTML5 (usually only in 360p quality variant - some videos with more relaxed copyright also come with an additional (HD) 720p variant). As before, there's no way to go full screen: The MP4 decoding relies on system h.264/aac decoders (Windows Media Foundation), which means you need installed both SP2 + Platform Update Supplement for Vista... OT: Notice in the top blue ribbon how Google are eager to push their own (spyware of a) browser, even on a currently unsupported platform (i.e. Vista)...

What is the current state of your Vista installation? Is it an old or a fresh install? Has SP1 been (manually) correctly installed? Then you should proceed with (manually) installing SP2, followed by installing Internet Explorer 9. Then search for (in MUC) and manually install latest security update for IE9 (2018-11 Cumulative Security Update for Internet Explorer 9 for Windows Server 2008 for x86-based systems (KB4466536)) Then you should manually install the latest update for Server 2008 SP2 that updates win32k.sys (previously known as "Update for the Windows Kernel") which, in all probability, is KB4056944; in the past, that was the decisive update to be installed manually that would speed up the whole process of checking for updates... I have stopped trying to manually update my system a while ago, so can't speak from experience on the latest state of affairs... Last things I read were that MS has applied to Server 2008 the same updating model as the one used in Win7SP1+, i.e. offering update bundles (Rollups) rather than standalone ones; and they may (?) have switched to TLS 1.2 for delivering updates, which should be an issue for a new Vista install (which only ever supported TLS 1.0); but this is pure speculation on my part... 2 hours isn't much , especially if you need to find a lot of updates ; better leave the machine running overnight, check back again in the morning... Also, some people had posted that installing the standalone version of the Windows Update Agent did help them: https://support.microsoft.com/en-us/help/949104/how-to-update-the-windows-update-agent-to-the-latest-version Download the "Stand-alone package for Windows 7 SP1 and Windows Server 2008 R2 SP1", once run, it will correctly detect Vista (NT 6.0) and install a Vista compatible version; after the installation and full restart, file wuaueng.dll should be at version 7.6.7600.256 For additional help, you'll have better luck, hopefully, if you posted in the forum's dedicated thread: https://msfn.org/board/topic/175919-windows-update-taking-forever/ and/or in https://msfn.org/board/topic/176686-server-2008-updates-on-windows-vista/ Hope I've helped...

I think this is because your original user account (username=FranceBB) was created when the base OS language was (and still is, in that respect) Italian... I think what you should try is create now a NEW Windows user account (e.g. username=FranceBB2), preferably within the Admins group (if you're the sole user on that PC) and see how that new account behaves... If it is to your liking, then you should permanently transfer over your personal (user) files and Windows settings to the new account and use only that (keep the old account around for a while, in case some weird issues pop up; to free up space on your disk, in the long run you should delete the old account, but this is up to you...). My suggestion/advice to you comes as a result of @heinoganda's post in another thread: Some might argue that creating a new user account in Windows and re-configuring it is not actually very remote from re-installing the OS itself, but still... Cheers

I honestly hope you did make a back-up of your FxESR 52 profile PRIOR to making the Quantum leap (pun intended) to FxESR 60; and even then, there's so much that has changed going from ESR 52.9.0 to ESR 60.3.0, that, if I were you, I would start by creating a new clean profile in 60.3.0 and then selectively transferring bits (e.g. bookmarks, passwords) from the backed-up 52.9.0 profile; I would re-install and reconfigure only those addons (WE format by default) that are truly Quantum compatible, all other addon stuff used in 52.9.0 should be left behind... Many people posted in the mozillazine forums they had sub-optimal results by doing an on-top upgrade... Though cumbersome, in the case of such major overhauls, it is advised one starts one's profile from scratch... 60.3.0 profile is not backwards compatible with the previous 52.9.0 one, so, again, a backed-up profile should be used when downgrading... Hopefully you already know all that and I'm just pointing the obvious, perhaps only for the benefit of other readers not fully aware... Cheers

It is all explained (but not in a convincing fashion) in https://bugs.chromium.org/p/chromium/issues/detail?id=451733#c19 https://bugs.chromium.org/p/chromium/issues/detail?id=451733#c66 as a result of: https://bugs.chromium.org/p/chromium/issues/detail?id=426573 TL;DR : At the time that decision was made, Vista user base was very thin, compared to either the XP or Win7+ one, so for code refactoring/simplification they decided to merge the Vista codepath to the XP one; for Google, it is only numbers that count ; plus, that gave them a perfect opportunity to dump Vista altogether (along with XP) a whole one year prior to Vista SP2 becoming EOL by M$ (and close to 5 years before Vista's Server counterpart, Windows Server 2008 SP2, reaches EOL in Jan 2020 ). Once Google made the first move (dragging along with them all webkit-based browsers), many other software makers soon followed (they had a "nice" justification) in a trend that put Vista, 1.5 years after its official EOL, in the sorry state it is currently in... The only way to properly fix this is to first grab the source for Chromium 41 (-50?) - Chromium, yes, because Google Chrome itself is closed-source - and then revert https://chromium.googlesource.com/chromium/src.git/+/f29562d138f8c2222c6f24bddbd1a665ed036658 Some additional details in https://bugs.chromium.org/p/chromium/issues/detail?id=426573#c10 => https://codereview.chromium.org/755293003/diff/1/ui/base/win/shell.cc#newcode153 This isn't a task for the faint-hearted ... You would need a Win7+, 64-bit, machine with lots of RAM and a powerful multi-core CPU, MS Visual Studio 2013+, lots of time/patience and, of course, you should be well versed in that field (compiling open-source browsers in VS)... Two MSFN members come to mind, @roytam1 and @FranceBB, but I am unsure whether they're interested in compiling Google Chrome 49.0.2623.112 (last officially supported build on Vista) or 50.0.2661.102 (last Vista compatible, but not officially supported) with Aero-Glass enabled in Vista... I, as much as other Vista users, would be all up for this, even if it is realised purely as a challenge only, given that both Chrome 49+50 are quite outdated (in both security and performance aspects) when dealing with the web of 2019... Those two screenshots @VistaPAE posted in OP are not from his own system ... First one is taken from https://bugs.chromium.org/p/chromium/issues/detail?id=451733#c83 That person compiled Chromium 49.0.2579.0 64-bit with the aero-disabling commits reverted... So did this one (Chromium 45.0.2415.0 64-bit) : https://bugs.chromium.org/p/chromium/issues/detail?id=451733#c68 The second screenshot in the OP is taken from https://bugs.chromium.org/p/chromium/issues/detail?id=451733#c67 It emerged that this was actually a hoax/cheat ; the OS used to generate the shot is Win7 SP1 64-bit, disguised as Windows Vista (much like @WinClient5270 's guide found in his signature...) So now you know PS: For the history of it, the last build on Vista SP2 with Aero turned ON was Google Chrome 41.0.2243.0 in the dev channel; I keep a portable copy of it on my system just for fun, it's not used for normal browsing: Next build 41.0.2245.0 had Aero turned OFF in Vista...

... This is to be expected ; only the (translated) strings for the fixes inside SP3 will change, some (basic) strings will remain in the base OS language (e.g. "Accessories" (All Programs) , "My Documents", "My Computer" (in the desktop), etc. will have stayed in Italian) ... From my linked article: Please also read this comment; it's from the (somewhat old) article: https://jekkilekki.wordpress.com/2009/01/05/changing-os-languages-in-windows-xp/ If you read through, you'll find how to revert your changes (you'll need SP3 in the original base language of your installation); while straightforward, the procedure is not 100% risk free, as can been seen in some of the comments; but the main challenge now is finding SP3 off-line installers for other (non-English) languages, since mom Microsoft has done its best to hide those links... EDIT: https://www.catalog.update.microsoft.com/Search.aspx?q=Windows XP Service Pack 3 (KB936929) (clicking the download blue button will generate a pop-up with additional language selection...) You may have to re-install some applications so they, too, display in English - it's the case of the ones that detect the OS language to determine the locale they should install in... E.g., I expect you'll have to re-install IE8 in English (and, perhaps, all of its updates), if you want IE in English, too... Ciao

The wikihow article I linked to has the Community Tested green badge, which signifies: But are you sure installing (unofficial) SP4 is the way to go?

@FranceBB : Italian (it-IT) is what is called the base language of your OS, and it can't be fully reverted to English (en-US) without an OS re-install; however, people have posted a workaround, which might solve your predicament... Funny thing is, the person asking for that in tomshardware site is a (supposedly) compatriot of yours, wanting to change from Italian to English: http://www.tomshardware.co.uk/forum/281286-45-change-display-language-windows-professional => "as far as I know there is only one way. SP3 + regedit" ; the youtube video guide has been long removed (probably at MS's request), but, thankfully, another site has saved it as complete instructions, including screenshots: https://www.wikihow.com/Change-the-Language-of-Your-Computer-(Windows-XP) I believe WinXP SP3 update (in en-US) is saved by MSFN member @sdfox7 in his server (but should be available in Microsoft Update Catalogue)... Worth a shot trying the procedure... Auguri

Please try Folder Options X : http://free-sk.t-com.hr/T800soft/software/FolderOptionsX.html https://github.com/T800G/FolderOptionsX It was suggested to me by a fellow MSFN member here but, sadly, I can't recollect his username, nor is it possible to retrieve his post: it was lost due to the forum's database corruption in early June of this year... Like WinXP, Windows Vista retains free sorting of folders+files, a feature that was removed by M$ in Win7+'s Explorer ; my preferred folder view in Explorer is Tiles, and the inability to freely re-arrange files/folders inside a directory drived me crazy on my sister's Win7 64bit laptop; but, thankfully, Folder Options X came to the rescue !!! Unzip and run the installer (if you want to be extra cautious, you can create a system restore point prior to the installation, I did not have to, everything went along fine...); be sure to check "Enable icon reordering" in the app's settings: what is unfortunate is that the app was released 4 Feb 2017, too long after Win7's own release... It does... But the MSFN member that recommended Folder Options X tried it on Windows 8.1 and it worked there! No clue whether it works on Win10; someone would have to try and report... Regards

Is that the old project you're alluding to?

... And you originally thought you wouldn't be able to fix my reported GitHub bug! This is superb We now have a fully working GitHub in latest New Moon 27, just out of the box! ... And to think that Tobin person () had the cheek to call you a lazy "developer"... Your actions speak volumes for themselves, can't stress enough how satisfied I am as a user of your builds!!! May God keep you blessed

Apologies for coming back to this, but I'm not the type of person that easily gives up I conducted further tests on FirefoxESR 38.8.0, MozillaESR 38.0 being the platform that Tycho is forked from, and, as expected, I can reproduce there the same bug I reported in New Moon 27... Searching to find the first Firefox version in which this bug was fixed (cause we already know it works in FxESR 52, hence UXP platform), I was lucky to discover that the issue is fixed in Firefox 39.0: Given that the ESR branch rarely contains any major feature enhancements (except for security+stability fixes applied to the Fx major version it is forked from), it is safe to assume that the code that fixes this is found in the changelog Fx-38.0...Fx-39.0. Searching on the net for "Fetch API + Request Payload + FormData", I found the following references: https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects https://hacks.mozilla.org/2015/03/this-api-is-so-fetching/ and, most interestingly, https://hacks.mozilla.org/2015/03/using-the-firefox-devtools-to-debug-fetch-on-github/ which mentions Bugzilla #1143857 ; As said, I'm not a coder, but, perhaps, is this what you need to apply to Tycho to fix the GitHub Comment Preview bug in New Moon 27 (provided fetch API is enabled) ? Thanks for your excellent user support, BTW

As a matter of fact, I do know @JoeyG ; he's a retired English teacher from the States, who currently lives in Germany with his wife and two beloved cats... I first met him in the mozillazine forums back in ca. 2012, when we were both Firefox Nightly testers He was an avid Windows XP + Firefox enthusiast; after XP's EOL, he had to update many of his machines to Win7 and, if it hadn't been for aris's Classic Theme Restorer extension, he would have jumped off the Firefox bandwagon as soon as Australis was enforced upon us... But the move to Firefox Quantum was a hard/bitter pill to swallow, so he ended up in Pale Moon Land... Reading his posts over many years, I feel there was no ill intent on his part in posting @roytam1's blog link in the Moonchild forums; his was a genuine query for additional info regarding the "forks", posted in a subforum (General discussion) where such queries would be totally fine... But then again, "Matt A Tobin" is lurking there, hence the repercussions... The mere mention of "XP/Vista/fork" is enough to ignite Matt and make him explode all over the place ; we all know that by now; I have taught myself to be immune of his insults and stay calm about it; in fact, "who fu*king cares" what he thinks... Roy's hard efforts are valued immensely by all those who get to use his builds! As for @JoeyG, perhaps @roytam1 can invite him via PM into this wonderful community, where members here are more tolerant of people's freedom of choice to use/keep using the OS they most feel comfortable with - or, in some cases, keep using the OS they are stuck with (i.e. it is impossible/impractical to move to a newer OS)!

Many thanks for investigating this... Since, sadly, I'm not a coder, I found it hard to understand what you were saying there (), but after some further examination of my own I managed, at least, to identify what you were referring to ... The following is from New Moon 27 where, as reported, github comment preview does not work: ... and the next one is from FirefoxESR 52, where github comment preview does work: It is unfortunate that this bug cannot be fixed in NM27/Tycho, but all is not lost; for the most part, Github is still usable there for an average user; for full compatibility with current Github, we have New Moon 28/UXP; plus, the other UXP browser, Serpent 52.9.0, can be made fully compatible with Github via a simple SSUAO, e.g. general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Goanna/4.1 Basilisk/52.9.0 (no reference whatsoever to Gecko+Firefox seems to be enough...) Likewise, in Basilisk (Serpent) 55/moebius I used: general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:53.0) Goanna/4.0 Basilisk/55.0.0 In FirefoxESR 52.9.0, which does not support SSUAOs, I used the HTTP Header Mangler v1.1.3 extension (WebExtension) with the rule: # Restore GitHub JS functions in 52.0 =< Fx < 59.0 github.com User-Agent= Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 Many other solutions involving XUL and/or WE addons exist for FxESR 52; I just found that one to be quite elegant, plus it doesn't overcrowd the browser toolbar with yet another button... BTW, 59.0 is the lowest Firefox version (in the UA string) that does not cause Github to complain about an unsupported browser... Two other browsers that are forked from FxESR 52, SeaMonkey 2.49.4 and Cyberfox 52.9.1, both support SSUAOs, so you can use the above Fx 60.0 UA string to restore GitHub on them... In closing, and while I'm not a Google Chrome person myself, I tried the last version of that browser that would run on Vista SP2, which is v50.0.2661.102; of course, GitHub would immediately flag Chrome 50 as an unsupported browser, but: 1. I installed User-Agent Switcher for Chrome extension; this one is capable of per-domain-UAOs 2. I configured the extension to spoof the Vivaldi (or Opera) browser on github.com; I first created a custom UA for Vivaldi (in the Opera group): and then used that in the extension's Permament Spoof list: (Vivaldi 1.2.470.11[beta] is the maximum Vivaldi version - based on Chromium 50 - that would run on Vista) I had first toyed with the idea of spoofing recent (> 65) Chrome versions to github, but that was not working; what really worked was spoofing either Vivaldi or Opera (and, not forgetting the original issue I reported here, "comment preview" does work in Chrome 50 !) ... Though I've not verified this myself, I estimate a similar procedure can be used to restore GitHub in Google Chrome 49.0.2623.112, the last WinXP compatible version... ... I do hope all the above is found to be useful, at least by some of you here...

Hello; I am sorry to report that your suggested fixes DID NOT cure my reported issue about GitHub Comment Previewing not working in (latest) NM27 I first created the string pref general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0 (Pale Moon) and then toggled dom.fetch.enabled so that now is: dom.fetch.enabled;true New Moon was restarted, then I accessed, e.g., https://github.com/rg3/youtube-dl/issues/17842#issuecomment-438809543 I cleared all Github cookies, cleared the browser cache, restarted and successfully logged-in anew to my Github account; I tried to edit my last comment in that thread and, again, Comment Previewing does not work, though this time Browser Console reports a different error: In case it helps, here is also the Request Headers window for the POST request for the preview: Any more ideas, please...? Thanks for your time spent already on this...

Latest New Moon 27 (Tycho platform) on Windows Vista SP2 32-bit; browser specifics: New Moon 27.9.1a1 (32-bit) (2018-11-02) buildID=20181102135253 Package filename: palemoon-27.9.1a1.win32-git-20181103-e1975531d-xpmod.7z As @CoRoNe has previously posted (here and here), I seemingly was unaffected by the recent GitHub changes: No top banner about an unsupported browser, browsing repositories and changing branches inside a repository without login in, all worked fine! Even when logged in, I could do everything I wanted, or so it appeared... Today I discovered one function that doesn't work, and this is Comment Previewing (either when writing a new comment or while editing an existing one ); the preview tab just displays "Error rendering preview", Error Console displays a ReferenceError on a big github javascript file: I then tried what was suggested by Roy here, i.e. creating a SSUAO for GitHub, restarted NM27 and tested anew, but this hasn't fixed the issue ; as is best recommended in the case of bugs, I repeated tests in, first, Safe Mode and, second, by creating a new pristine NM27 profile (all to no avail...). Can anyone here with a Github account reproduce? @roytam1: Is there a possible fix for this in Tycho, or should I give up Github altogether in NM27? FTR, everything GitHub related (i.e. including Comment Previewing) works as expected in latest NM28 out-of-the-box (without a SSUAO), but I still prefer to run NM27 when I have a choice, it being more responsive and gentler on resources in this old hardware of mine... Again, many thanks for your invaluable efforts!

Both the main executable and the wxWidgets DLLs, when inspected with a HexEditor, reveal dependencies on missing stub dlls kernelxp.dll and advapixp.dll; I am not at all savvy in this field, but presumably these stub DLLs handle (redirected) API calls not present inside XP's proper dlls, i.e. kernel32.dll and advapi32.dll; obviously, more expert members here can elaborate on this, I have just scratched the surface... Perhaps @FranceBB forgot to include them in his package, or assumes they are to be easily found elsewhere... BTW, you'd also need msvcp140.dll and vcruntime140.dll present in the folder for the app to run, if, that is, you don't have the redistributable for MSVC++ 2015/2017 installed system wide...

I was intrigued by what you have posted so I decided to create a new clean/minimal Serpent 52.9.0 profile; some basic GUI settings were changed, then I proceeded to only installing Greasemonkey 4.1 (WE, from AMO), followed by installing the SF.net userscript from their site (you have to cut-off the timestamp bit, ?ts=..., from the URI there, because GM will only install scripts from URIs ending in user.js). I restarted Serpent, headed off to a youtube clip and, apparently, everything was working fine: Well yes, I do expect Moonchild's Basilisk and Roytam1's Serpent 52 (both on the UXP platform) to have the same WE APIs, so I am puzzled as to why you didn't manage to get GM 4.1 working in your Serpent install (on XP) ; perhaps a conflict exists there between one of your other extensions and/or a modified browser setting??? FWIW, I can't test official Basilisk here, since it requires Win7+ My previous comment to you wrt GM 4.1 was half "educated guess" and half "from experience" ... When it comes to Serpent 52.9.0 and Webextensions, I have always found it to be a case of trial-and-error ; WE addons from AMO that would install fine in FirefoxESR 52.9.0 and then perform there as expected, would either not install at all in Serpent in the first place (yielding the infamous "appears corrupted" error message) or, after initial successful install, would underperform or not work at all... That is why in Serpent, much like in NM, I'll opt for the XUL edition of an extension, provided there's still choice (so I use XUL GM but WE SF.net - there isn't anymore a legacy version of the latter available). Cheers

Hi ; I did some tests on my Vista SP2 laptop running yesterday's release of New Moon 28 (appVersion=28.2.0a1 (32-bit), buildID=20181027020958) and those tests showed conclusively that: Native UA: Mozilla/5.0 (Windows NT 6.0; rv:52.9) Goanna/4.1 PaleMoon/28.2.0a1 Gecko compat UA: Mozilla/5.0 (Windows NT 6.0; rv:52.9) Gecko/20100101 Goanna/4.1 PaleMoon/28.2.0a1 Firefox compat UA (this is my current setting): Mozilla/5.0 (Windows NT 6.0; rv:52.9) Gecko/20100101 Goanna/4.1 Firefox/52.9 PaleMoon/28.2.0a1 so, in reality, "Goanna/4.1" and "Pale Moon/28.2.0a1" are not replaced, but always remain in the advertised UA string; if you want to hide them completely from a certain site, you'd have to use a custom UA string (either via the native way, setting a SSUAO in about:config, or via an extension). There's a hidden (i.e. not exposed in a GUI setting) string pref inside about:config called general.useragent.compatMode.version which defaults to 52.9 ; by modifying it to a more recent Fx major version, those sites might be tricked into thinking you're running an up-to-date Firefox version; e.g. with the "Firefox compat" UA mode and that pref set to "63.0", my advertised UA string is: Mozilla/5.0 (Windows NT 6.0; rv:63.0) Gecko/20100101 Goanna/4.1 Firefox/63.0 PaleMoon/28.2.0a1 This approach, however, is not risk free, because you stand the chance of a site serving you code (Javascript, CSS, etc.) - intended for your "advertised" Firefox version - that NM28 is just not compatible with... So, as you said, you'd have to experiment a bit - as you put it, YMMV...

GM 4.1 is of the WebExtension format and is dependent on WE APIs not present inside Basilisk52/UXP (which, as stated numerous times, has only a limited subset of WE APIs compared to FxESR 52); if you want to install GM on Basilisk, go for the XUL (legacy) version 3.17 or the PM fork 3.31.4 If, OTOH, you insist on installing a userscript manager of the WE format, latest Violentmonkey 2.9.9 works fine with Basilisk (both 52/UXP + 55/moebius)... The WE addon from SF.net has a feature that enables you to selectively disable/enable it per site; perhaps that's what you need (not tested, as I don't have an account with chase.com ): Regards

Matt A. Tobin spewing, once more, poison against Vista users and against the New Moon fork: #817#issuecomment-433252852 The fact is I got prior clearance from Moonchild himself to report bugs (found in New Moon 28 on Vista) in the GitHub issue tracker, if: 1. The bug has been also reported in the Palemoon forum by users of the official PM builds 2. I could replicate the bug I found by using an official build on Win7+ So that is why I got involved in #817#issuecomment-427697783 Honestly, I find all that hostility from Tobin to be totally unwarranted... Mind you, I refuse to even dignify his response by trying to argue with him; we all know by now he's a nut case... I will accept his code contributions to PM but am not prepared, nor willing, to accept his attitude (rant over...)

... From their Support section: Why is my domain status set to 'Suspended'? I can't see anything that would, even remotely, apply to your case...