Jump to content

InterLinked

Member
  • Posts

    492
  • Joined

  • Last visited

  • Days Won

    4
  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by InterLinked

  1. On 3/13/2024 at 6:24 PM, ThorPan said:

    Hello InterLinked,

    I know it's been over 3 years since you last posted about getting updates for MS Office 2010 Pro x86 version, but I just can't give up on my copy on this new machine.  I recently purchased a new Dell machine with Windows 11 Home and want to install my original copy of Office 2010 Pro that currently resides on my Windows 7 machine.  I already have the SP1 and SP2 installation files saved on the old machine.  I've read all 6 pages of your trials and tribulations, but the one thing I've apparently missed is where is the file that you created containing all of the updates after that SP2?  I do NOT want to give up my Office 2010!!  It does all we need and more, so don't wanna pay MS for stuff I don't need nor want.  I know, for about $400 I can upgrade to Office Pro 2021, but I'm pretty sure that MS isn't going to release anything new after that since they're moving to the pay-as-you-go model for Office.

    Any assistance you or anyone else can provide would be GREATLY appreciated!!!

    Thanks,
    ThorPan

    Hi @ThorPan

    It is definitely doable, I am still using Windows 7 and Microsoft Office 2010 and have no plans to change that, ever.

    I have no interest in the newer garbage, I get free 365 licenses through work and such, but 365 sucks so bad I have no desire or interest in using those.

    I did have to install Outlook 2016 about a year or so ago since Microsoft now blocks Exchange access to Outlook 2010, so they did prevent me from using Outlook 2010 :realmad: but at least I have the rest of Office 2010 still 

    It's been so long my memory may be faulty, I don't think I ever published a file with the updates, I only published instructions and data on update supersedence. Anything I did publish on this would likely be here: https://w2k.phreaknet.org/

    Locally on my network, I have all the extracted files on my deployment server, so whenever I PXE boot and reimage a machine using MDT, it gets the latest slipstreamed Windows 7 with any software I elect, including Office 2010 as best patched as I can. I haven't updated the update list in some time though I think updates for 2010 have been discontinued for some time now anyways. I guess the one silver lining is I no longer have to worry about regular software updates or maintenance :P

  2. 17 hours ago, InterLinked said:

    Yeah, seems to be the case now actually after more testing. What's not working is when I cross compile on Linux for Windows, which I need to do to incorporate custom FileZilla patches (TL;DR, see this project: https://github.com/InterLinked1/fastfilezilla)

    I did this once before but didn't compile with the update nags turned off, so I need to do it again with that option passed in, and every build I've produced so far results in that missing API error:

    The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll.

    Finally managed to build a working cross-compiled version.

    Since the previous one was built on a different system, perhaps Windows 7 was implicitly supported then, but I had to be explicit about maintaining Windows 7 support this time around.

    This version also has updates disabled, so for those who don't want to see nags about updates, this may also be of interest, in addition to the speed improvements - source and binary available here:

    https://github.com/InterLinked1/fastfilezilla

  3. Yeah, seems to be the case now actually after more testing. What's not working is when I cross compile on Linux for Windows, which I need to do to incorporate custom FileZilla patches (TL;DR, see this project: https://github.com/InterLinked1/fastfilezilla)

    I did this once before but didn't compile with the update nags turned off, so I need to do it again with that option passed in, and every build I've produced so far results in that missing API error:

    The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll.

  4. FileZilla no longer supports Windows 7 it seems (and the author definitely has no qualms about that, given his, er, very made up views about certain things).

    3.65.0 is definitely not compatible, but 3.62.2, the last version I used, was.

    Does anyone know off hand what the last compatible version was? It's not documented on the website (probably intentionally), and I have to cross-compile FileZilla myself, which is extremely arduous, so trial and error is not really an option.

  5. I've been really struggling with this issue lately, so I'm wondering if anyone else has been having a similar issue.

    I use Windows 7 as my primary OS, with Office 2010 as my primary office suite, and for a long time, until mid last year, I used Outlook 2010 to access my calendar and contact. I use Roytam1's MailNews as my primary email client, as Outlook sucks at actual email, but I love it for Exchange access to my calendar/contacts, for a personal Microsoft account.

    At some point last year, 2010 stopped working due to the basic authentication shutoffs that Microsoft was doing :realmad:

    So after cursing them to the moon, I installed Outlook 2016 on my PC, keeping the rest of Office 2010, so I could continue to access my calendar. At the time, it was a necessary evil to function.

    I hadn't used that machine in a little while due to traveling and such, and when I came back, I reimaged the machine as part of joining it to a domain and getting a fresh setup. I found that Outlook 2016 would no longer connect to Exchange accounts. With suitable updates, it can connect using IMAP just fine, but I don't want IMAP; I use a better client to do IMAP. It must be Exchange.

    I've now spent probably 10 hours troubleshooting what could be the issue - software updates, network issue, DNS, TLS negotiation, etc. I've looked into everything. Finally found a working version of Outlook 2016 at another site and installed verbatim on a Windows 10 VM here, and it worked. But when I did the same on a Windows 7 VM, it did not.

    Microsoft obviously says that Win7 is not supported, blah, blah, blah, but it was working just in the past couple months, so I think it's unlikely that something has changed in that time.

    Would anyone happen to know what the missing puzzle pieces might be to making this work? Since the only difference here is the OS, are there certain files that differ between the two versions of Windows, that could make a difference?

    Because Outlook 2016 is the newest version supported on Windows 7, this is an issue that is bigger than just Outlook 2016, it is literally about being able to access my calendar using ANY version of Outlook, on Windows 7. It is unbelievable that Microsoft is deliberately screwing with people as much as they can. I wish I could send them an invoice for all the time of mine they've wasted here!

    At some point I'll probably be forced to set up an on premises Exchange server, just so I can have calendaring access (it must be accessible from multiple machines), but I wasn't planning to do that this year. I'd like to keep using Outlook 2016 as long as it's supposed on any OS (which it should be until 2025).

    Any help here would be a lifesaver, thanks!

  6. I'm not sure if this is by design, but seems like a potential bug since this is completely ambiguous:

    I have about 20 email accounts set up in MailNews, but just recently I have been experimenting with multiple IMAP namespaces (Other Users, Shared Folders).

    I granted myself access to another account, and in the normal view, everything looks fine. However, in Unified view, any of the same types of folder are named exactly the same.

    For example, if I have access to both John's inbox and my inbox, they both just show up as inboxes for the main account:

    Perhaps the Unified View is not properly namespace aware? These have different IMAP paths, and yet they show up as exactly the same.

    Sure, with just 2, maybe I can guess the 2nd one is John's INBOX and the first one is my personal one. But say I have access to six people's INBOXes, how are people supposed to tell which is whose?

    image.png.1cbe6d28711abe263e33aca0b02390f0.png

    EDIT: Sorry, not sure why I said INBOX, I mean the non-Inbox folders, e.g. Sent, Junk, Trash, etc. that are all named the same.

  7. ... and to make it worse, it doesn't seem the profile can be moved.

    I *copied* (I suspected moving might be a bad idea) the old profile folder to the new location.

    Initially I got all the standard welcome new user stuff when opening MailNews.

    Now I get:

    image.png.cbef519852cba9ae841aae49f714efb3.png

    Ugh.... I'm an id*** now for upgrading these programs "just cause"... I really just wanted the updated New Moon for the nullish coalescsing/optional chaining support, not this whole can of worms. If there's no way to fix this, I literally have to spend 4 hours setting up my email and another 8-12 hours syncing it. Biggest headache ever.

     

    -

    Okay, looks like moving the *contents* of the profile folder as opposed to the profile folder, and overwriting all the default files, does work.

    The folder statistics had to rebuild, but at least no lasting damage appears to have been done - my email is back in business.

     

    Now I just need to figure out the New Moon stuff. I didn't have many customization to it, I can rebuild it if necessary and don't mind much, but it would be nice to be able to migrate the profile folder if that can be done.

  8. Okay, don't mean to go off on a rant here, but seriously, WHO CHANGES THE PROFILE LOCATION in MailNews?

    I've upgraded MailNews before, usually a couple times before, along with New Moon, and it's all gone well before using my auto install scripts, since it upgrades the application.

    However, it now appears to be looking in %userprofile%\AppData\Roaming\OpenSource\MailNews instead of %userprofile%\AppData\Roaming\Binary Outcast\Interlink\Profiles

    This is a *HUGE* break in compatibility and a divergence from the previously offered backwards compatibility.

    Sorry if I missed some announcement about this or something, but this is a huge change that is bound to mess up the entire userbase. I have 11 email accounts and 8 GB of email, it literally takes 3 hours to get the email accounts setup properly in MailNews. (Modern TB, to give it credit where credit is due, is way way faster, maybe less than half an hour. Interlink still uses the obsolete conception of separate IMAP and SMTP servers for who the heck knows why, which makes configuration of Interlink/MailNews a total PITA)

    And it seems the same thing has happened with New Moon as well - EVERYTHING is gone, and I can't even locate where the new profile folder is yet to move stuff from the old one to the new.

    Okay, sorry, </rant>, but this definitely made for a grumpy morning and in the future - please, please - such ABI changes should really be avoided unless absolutely necessary, this seems like it wasn't to me, changing Binary Outcast\Interlink to OpenSource\MailNews. At least now that it's happened, hopefully it won't change again.

    On a different note, much thanks as always for your continued development on these awesome forks, hope they will continue to be around for a long time! :)
     

    But also serious question - WHERE did the New Moon profile folder move to??? I can't find it.

  9. 2 minutes ago, VistaLover said:

    Without me sounding pessimistic, any effort in 2022 targeting Chrome 49, for the benefit of XP/Vista users, is a futile one...

    Chrome 49 is extremely outdated by today's WebCompat standards, not to mention security wise (has more holes than Swiss cheese...)

    That's true, I would never use it myself.

    New Moon on Windows 2000 can do TLS 1.3, I'd have no reason to use Chromium on an older system.

    2 minutes ago, VistaLover said:

    It practically unsupported by Google store, as it only supports CRX1 extensions, when even CRX2 ones are en mass being phased iut in 2022 (and would be fully deprecated in 2023); I keep a copy of it myself, and I can tell you it's a "dead man walking"...
    Under XP, you would definitely need to couple it with a TLS 1.2/1/3 secure proxy to access most of today's sites, but rendering is dire...

    Supported by the Google store is irrelevant, since the entire Google store is irrelevant to old Chrome as it is. chromefill is manifest v2 which is no longer accepting new ones anyways.

    It's a fact of Google that you are on your own at this point and if you want to make an extension targeting old browsers, it will NEVER be in the store and you'll have to upload it manually from source using developer mode.

    Does make me think: we should probably save all the important Manifest v2 Chrome extensions locally before they're removed from the Chrome Web store. Or at least, be able to get them locally from source, e.g. uBlock Origin

    2 minutes ago, VistaLover said:

    If you intend to bridge all the missing Web APIs introduced after Ch49 (to, say, chrome 70 stage) via polyfills, that would be a pharaonic task, if at all feasible... But be my guest, of course...

    With just GitHub in mind, they provide a facility/wizard with which one can inspect all MISSING Web APIs in the client for it to fully support their latest GitHub incarnation:

    https://github.github.com/browser-support/

    Currently latest St52 has as missing (in RED) only customElements and RegExp Named Capture Groups, so support for these has currently to be implemented via an extension (i.e. palefill); I fear that wizard, if at all rendered in Chrome 49, would have many RED entries...

    And for me, only NC and OC are red :realmad:

    2 minutes ago, VistaLover said:

    Using the wizard with declining Chrome versions (starting at v69 and going down by one major version), you can test which minimum version is currently supported by the extension as-is and then decide how "low" in the Chrome versions you want/is feasible to extend support to (on the availability of polyfills for the missing APIs as you go down the range...).

    Right, and maybe 49 is a bit too low but I think the 60s are quite doable.

  10. Just now, VistaLover said:

    ChromeFill isn't intended for such an old a Chromium version, unfortunately... :(

    BTW, and this has been discussed quite a few times in the MSFN forums, be it in the past, Advanced Chrome wasn't essentially based on Chrome 54; much of it is in essence Chromium 48 based, with only traces of code borrowed from Ch49/52/54...

    @InterLinked should have been more verbose in his README.md and/or enforce a minimum Chrome version in his extension's manifest.json, so as not to create false expectations...
    I haven't tested fully all the range of Chrome versions in which the extension successfully restores GitHub and other supported sites, but as an educated guess I'd claim that anything under Chrome 68(-ish) is unsupported...

    As I stated already, ChromeFill for XP/Vista users currently only targets 3360EEv11/12...

    Ideally, I would like for the extension to support those versions that might not work now, such as between 48 and 68. I use 70 since that's the last usable version, but obviously folks on Vista are older will be on 49, and other folks may be on other versions inbetween.

    The reality is though that I don't have the ability to test all these different versions for breakage, so it's up to the community to report any issues on the issue tracker, otherwise I simply don't know about them. I have tried to keep up with reported issues that way to add polyfills where needed.

    So officially it should support all of these versions and if it doesn't, that's a bug that would be great if folks could report.

  11. 1 minute ago, AstroSkipper said:

    I've already tested the ChromeFill 0.1 extension in Advanced Chrome (CH54-based), and unfortunately, GitHub doesn't work properly. I couldn't note any differences with or without ChromeFill. The account menu is completely broken, and pop-up boxes, too. :( In 360EEv11, no need to add a Polyfill extension at the moment. All functions I need to use are working. :)

    What errors show up in the developer console when you do this?

    I only test on version 70, so it's entirely possible that there are things supported by my browser that aren't by yours (introduced between 54 and 69).

  12. 8 minutes ago, VistaLover said:

    For GitHub exclusively, you may want to have a look at
    https://github.com/martok/palefill/issues/29#issuecomment-1186046465
    and
    https://github.com/dirkf/palefill/commits/df-optchain-patch
    https://github.com/dirkf/palefill/releases/tag/v1.19df

    The dev(s) use simple transpiling JS code for just those two operators, nothing more (the rest can be handled by polyfills, like already done in your extension). You might have to ask kindly though ;), because the dev(s) are primarily concerned with SM 2.53.12 and/or PM < 31 support... :(

    That's probably a lot better than Babel, yes!

    You can filter by using data-plugins it seems, but I'm not noticing any performance difference. It still takes about 15 seconds to run on GitHub.

    The code seems simple enough, but I'm not a great JS dev, nor I am super familiar with modifying JS via Chrome extensions, so it'll probably be a fair amount of hacking to try to figure out how to kludge that in.

    8 minutes ago, VistaLover said:

    Target groups for a "fixed" GitHub via your extension, ChromeFill, would be most XP+Vista users on low-end HW, currently using 360EEv11 (Ch69-based) and/or 360EEv12 (Ch78-based) ...

    I dunno, target group is ANYONE to me using a non-screwed UI Chromium version.

    I use Chromium 70 on Windows 7 and Windows 10. OS and hardware are completely irrelevant. This extension is necessary to get Chromium to work properly on the web these days (and the NC/OC support is unfortunately an almost-must-have at this point).

    8 minutes ago, VistaLover said:

    I would have been quite taken aback, had they actually done anything... GitHub's fate is under Microsoft's rule for years now, they're currently focused on their latest crapware/adware Windows 11 OS, together with their illicit lovechild, Microsoft Edge (the "fruit" of them having intercourse with Google :angry: ...); I'm confident they don't give a rat's a** about Net Neutrality or have any iota of intention to support those marginal "few" still on browser-engines not compatible with the evil operators (already implemented in Chrome 80...); BTW, I did "upvote" your - currently still "unanswered" - GH community issue; 3 weeks have now gone by, it's quite telling that no official GH dev will act on it... :realmad:

    Yup, truly horrible. Shows how much they really care about "open source" and "projects"... when they don't even practice what they preach.

  13. On 3/24/2022 at 12:35 AM, xrayer said:

    Well, so the problem of RB is they use too new JS syntax that is not supported by old browsers. How Polyfill Addon can help with it? It doesn't work with Seamonkey but can be installed in MyPal. Or could be helpful Grasemonkey plugin to inject/patch some code?

    Is there any chance to implement newer JS interpretter into some XP browser?

    I've finally been able to incorporate automatic transpiling into my extension for Chromium browsers, so a lot of sites theoretically might be unbroken by this.

    GitHub for example now works fully again on my system. However, there are some caveats, crossposting:

    Good news and bad news.

    Bad news: GitHub still has done diddly squat about their use of the evil operators. Thanks to those who have given this a thumbs up, I  think personal comments explaining how this has impacted YOU (or how you feel about it) would also be good: https://github.com/community/community/discussions/20973

    Good news: I have managed to incorporate automatic transpiling capabilities into the Chromefill extension. This means that GitHub now works fully again in old versions of Chromium. See https://github.com/InterLinked1/chromefill

    More bad news: Unfortunately, this is not an elegant solution and probably never will be. Transpiling is SLOW. Reeaaaaaaalllllllllllllllyyyyyyyyyyy sssssssssslllllllllllllooooooooooooowwwwwwwwwwwwwww. It takes about 15 seconds to fully transpile GitHub with all the garbage that they use on their site, and this is blocking. Transpiling is also very CPU and memory intensive (think compiling, essentially). It's also page blocking, so you can't interact with it and transpiling is done. In the case of GitHub, since it's mostly a single page app, that actually means you only need to do it once per tab and afterwards everything just works for your browsing session, but still, not pretty.

    Sites that don't use JavaScript or use minimal JavaScript don't really see any impact. It's only very bloated sites with hundreds of thousands of lines of JavaScript like GitHub that see a significant performance issue.

    I think it could be sped up if we could incorporate a transpiler that only focused on these two syntax issues rather than everything, but I'm not sure if such a thing exists.

    I repeat, this is not really a solution, it's more of a hacky last resort that can force things to work when sites like GitHub behave idiotically and moronically and refuse to do the right thing.

    That said, if this functionality is useful, by all means go for it.

    Because of the impact this can have on a site, this functionality is not enabled by default in the extension, it has to be whitelisted per domain. Currently, only github.com is on the list, because that's the only site I use that has this issue. If there are others, feel free to let me know or submit a PR to add it to the list. The goal is to not enable that functionality unless it's actually necessary for a site to work properly.

    Anyways, happy browsing, if you do use this, let me know how it works out for you.

  14. All right, everyone.

    Good news and bad news.

    Bad news: GitHub still has done diddly squat about their use of the evil operators. Thanks to those who have given this a thumbs up, I  think personal comments explaining how this has impacted YOU (or how you feel about it) would also be good: https://github.com/community/community/discussions/20973

    Good news: I have managed to incorporate automatic transpiling capabilities into the Chromefill extension. This means that GitHub now works fully again in old versions of Chromium. See https://github.com/InterLinked1/chromefill

    More bad news: Unfortunately, this is not an elegant solution and probably never will be. Transpiling is SLOW. Reeaaaaaaalllllllllllllllyyyyyyyyyyy sssssssssslllllllllllllooooooooooooowwwwwwwwwwwwwww. It takes about 15 seconds to fully transpile GitHub with all the garbage that they use on their site, and this is blocking. Transpiling is also very CPU and memory intensive (think compiling, essentially). It's also page blocking, so you can't interact with it and transpiling is done. In the case of GitHub, since it's mostly a single page app, that actually means you only need to do it once per tab and afterwards everything just works for your browsing session, but still, not pretty.

    Sites that don't use JavaScript or use minimal JavaScript don't really see any impact. It's only very bloated sites with hundreds of thousands of lines of JavaScript like GitHub that see a significant performance issue.

    I think it could be sped up if we could incorporate a transpiler that only focused on these two syntax issues rather than everything, but I'm not sure if such a thing exists.

    I repeat, this is not really a solution, it's more of a hacky last resort that can force things to work when sites like GitHub behave idiotically and moronically and refuse to do the right thing.

    That said, if this functionality is useful, by all means go for it.

    Because of the impact this can have on a site, this functionality is not enabled by default in the extension, it has to be whitelisted per domain. Currently, only github.com is on the list, because that's the only site I use that has this issue. If there are others, feel free to let me know or submit a PR to add it to the list. The goal is to not enable that functionality unless it's actually necessary for a site to work properly.

    Anyways, happy browsing, if you do use this, let me know how it works out for you.

  15. 26 minutes ago, dmiranda said:

    It would make sense. W7 was the last non-spyware (if well set up) version of MS. W8 already was banned for governmental use in GE among others, I reckon. Many will resist (or be prevented from) "upgrading" from W7 and move to linux if support is not extended.

    Yup...

    But don't let MS tell you what OS to use. Support is a benefit, but not a requirement.

  16. 1 hour ago, DrunkenTanker said:

    I suppose that to leave Github is the best way. I have lost too much time.
    It they want to make experiments then without me. I'll move to more constant system.

    Well, **tell them that** in that case. A boycott that they don't hear about has no effect!

  17. The reason GitHub doesn't work anymore as of the past few weeks is because of nullish coalescing and optional chaining. Unlike everything else, these can't be polyfilled which is why they are a disaster for the WWW. See the bottom of the README for more details: https://github.com/InterLinked1/chromefill (also https://blog.interlinked.us/69/nullish-coalescing-and-optional-chaining)

    The maddening thing is that GitHub tried this before briefly, realized there was massive breakage, and then went ahead and reverted it. They apologized and said they would not do it again. They actually did the right thing! That was several months ago, earlier this year.

    Then, without warning, they went ahead and deployed it again, which means **they lied to us** and actively decided to screw us with operators that serve no legitimate purpose in the first place. Their justification is that it allows for a size reduction which increases performances (you know, since you save a character each time you use it). I call BS. The website isn't performant at all if **it doesn't freaking work**!

    Basically, GitHub seems to have decided that it the small gain in bandwidth reduction (for files that are generally cached anyways) is more important than breaking compatibility with literally most of the web browsers in existence, those that aren't by "the big 3" from the past year or two.

    I highly urge everyone to take a minute and file a GitHub support ticket. They do read tickets and do engage with people, and they need to be aware that this is not acceptable. Even if you don't actively use GitHub, it still helps as if we lose GitHub, then that is a big loss for open source, diverse browsers in general.

    You can submit a ticket here: https://support.github.com/contact

    You don't have to write essays to them like I have - just take 2 minutes letting them know how this has impacted you and how you feel about and how GitHub has let you down by doing this.

×
×
  • Create New...