I'm working on a new E-mail client for UXP.

[athenian200]

I use Win 7 pro and only apply security updates so that's probably why it was asking to install updated Visual C++ files.
You're right - Epyrus is not the one for me, yet. I forgot it's still in the development stage !

It turns out that was actually an oversight on my part. The .mozconfig I used to build it didn't include the redistributable files with the application, which is supposed to prevent situations like the one you encountered. A lot of applications on Windows 10 or later are now built with newer Visual Studio, which means I would never have seen this issue.

Would you be willing to test it out with an account or two without making it your primary application you rely on? I do need people to test it, but I really want them to use something else as a fallback so that they aren't in the position of needing it to work for mission-critical situations and having to rely entirely on me for support.

I did take your feedback about struggling to extract the archive into consideration, though. Future builds will likely be distributed as .zip files... the decision to distribute them as .7z wasn't mine anyway, the platform just got setup to do that and I didn't think to question it.

[Giraffe]

Pardon my ignorance, but something that I've never grasped is how to update a Portable app. without losing the settings.
I've always looked at the old and new and copied across the new files whilst avoiding any that seem to contain details that I need, but is there a neater (i.e. easier) way, please?

[Baloo]

I forget, is Baloo on Windows or Linux? I should have asked that... if he's on Linux too, then it is good to hear that the bridge is working for someone else.

Baloo writes about using Linux. Last time Baloo said which distro was in use, I believe it was PopOS.

Yes, I am using Pop OS 22.04. The Protonmail Bridge works fine for Thunderbird and also worked fine for Interlink. Epyrus is able to start syncing emails, but halfway through loading the inbox it automatically crashes. I am unsure if this is an email capacity problem or what. How do I obtain the logs?

[athenian200]

Pardon my ignorance, but something that I've never grasped is how to update a Portable app. without losing the settings.
I've always looked at the old and new and copied across the new files whilst avoiding any that seem to contain details that I need, but is there a neater (i.e. easier) way, please?

This isn't a portable app, though. That is to say, the settings are not stored in the actual application directory. So it's generally safe to unpack the new version on top of your existing one and replace files. And even if you unpacked it elsewhere, your profile would still be intact and usable because that's stored in AppData rather than in the actual application folder.

It's really looking like most users require a level of automation and ease of use that I cannot easily provide without actual services and infrastructure that I am not really in a position to provide. They want automatic updates and get confused by anything less than a full installer... sigh. I'm going to look into a solution before I proceed to the beta/2.x phase.

[athenian200]

Yes, I am using Pop OS 22.04. The Protonmail Bridge works fine for Thunderbird and also worked fine for Interlink. Epyrus is able to start syncing emails, but halfway through loading the inbox it automatically crashes. I am unsure if this is an email capacity problem or what. How do I obtain the logs?

I don't know what to tell you about crash logs. I don't think we have nice, neat crash logs that can be exported from an interface inside the application. The only thing I've ever gotten in the aftermath of a crash, if I'm lucky, is a core dump that contains a stack trace. I know how to process that if you have it, but I don't know anything about crash logs like you are talking about. If that's in there, I've never been told how to access them.

[andyprough]

Yes, I am using Pop OS 22.04. The Protonmail Bridge works fine for Thunderbird and also worked fine for Interlink. Epyrus is able to start syncing emails, but halfway through loading the inbox it automatically crashes. I am unsure if this is an email capacity problem or what. How do I obtain the logs?

Have you tried starting Epyrus with:

Code: Select all

./epyrus --browserconsole

It has a console with a logging tab. If I click around on the console tabs, I get a little bit of information (see attached). Not sure how useful it is.

2022-07-25_11-56.png

[Giraffe]

Pardon my ignorance, but something that I've never grasped is how to update a Portable app. without losing the settings.
I've always looked at the old and new and copied across the new files whilst avoiding any that seem to contain details that I need, but is there a neater (i.e. easier) way, please?

This isn't a portable app, though. That is to say, the settings are not stored in the actual application directory. So it's generally safe to unpack the new version on top of your existing one and replace files. And even if you unpacked it elsewhere, your profile would still be intact and usable because that's stored in AppData rather than in the actual application folder.

It's really looking like most users require a level of automation and ease of use that I cannot easily provide without actual services and infrastructure that I am not really in a position to provide. They want automatic updates and get confused by anything less than a full installer... sigh. I'm going to look into a solution before I proceed to the beta/2.x phase.

Thank you for this.
I did it by unzipping to a folder that was named epyrus-1.1.0.win32, inside which was a folder named epyrus. I copied the total contents of that to the working folder, allowing override of all.
Epyrus wouldn't run, saying: "epyrus.exe - System Error
The program can't start because api-ms-win-core-libraryloader-l1-2-0.dll is missing from your computer. Try reinstalling the program to fix this problem."

Downloaded the .dll and put it into C:\Windows\System32. Now there was no response from the shortcut or epyrus.exe, even the newly downloaded one.
Obtained the previous version, went through copy/replace again - nothing. Renamed the working folder, copied the new epyrus 1.1.0 to Program files and away it went with all the settings intact.
So, working again but updating seems to be no-go for now.

[Moonchild]

Just downloading a dll from a random site is never a good idea.
To solve this for now you should install the visual C++ runtime libraries for visual Studio 2022 (this is a free download from Microsoft), and "universal CRT libraries" for the same. I'm not exactly sure how Microsoft has named these redistributables for end-user installs though.

[billmcct]

Here:
https://docs.microsoft.com/en-us/cpp/wi ... w=msvc-170

[athenian200]

Thank you for this.
I did it by unzipping to a folder that was named epyrus-1.1.0.win32, inside which was a folder named epyrus. I copied the total contents of that to the working folder, allowing override of all.
Epyrus wouldn't run, saying: "epyrus.exe - System Error
The program can't start because api-ms-win-core-libraryloader-l1-2-0.dll is missing from your computer. Try reinstalling the program to fix this problem."

Downloaded the .dll and put it into C:\Windows\System32. Now there was no response from the shortcut or epyrus.exe, even the newly downloaded one.
Obtained the previous version, went through copy/replace again - nothing. Renamed the working folder, copied the new epyrus 1.1.0 to Program files and away it went with all the settings intact.
So, working again but updating seems to be no-go for now.

Which version of this did you download? Was it the one labeled 1.1.0? If it was, that was actually already obsolete. I uploaded another after someone else had the problem before:

I believe I've solved the issue with the CRT not being distributed with the application. So, here's a quick redo of the Windows builds:

https://1drv.ms/u/s!AsscXELhr-eyh71QNDF ... g?e=y0auqx

If the new version is having the problem too, I would really like to know about it. I marked those builds 1.1.1 to differentiate them from the broken ones. There is the possibility that even with everything pointed to the right place, the package-manifest is out of date and not copying over all the files needed for the new compiler. In other words, the new version contains a whole bunch of files that start with "api-ms-win-core" that I forgot to distribute with the old one.

It seems like this is becoming a big problem very early in development... I posted a fix for the problem, but because the broken build was more visible, you probably downloaded that one instead. I really feel like I am in way over my head with trying to actually publish software. I'm in this awkward situation where multiple people have had the same problem, but I can't be sure if it's because they keep downloading a known broken build or because the new one still has the problem.

One thing I do want to commend you all for, though, is that it seems like every single person that had the problem figured out how to deal with the problem of missing CRT dll files. It was obviously inconvenient, but you all had enough of an idea of what was wrong to know how to fix it on your own. I guess we've all dealt with apps that fail to distribute that and had to download it at some point. It's just too bad my application is now one of them. LOL.

[athenian200]

How do I obtain the logs?

I asked around, and it turns out that it's not really possible to generate crash logs on Linux. There is a way to do so on Windows, and that is one of the reasons why Windows is preferred for development. The ability to generate crash reports seems to have been removed along with telemetry, because the tooling needed to do that on Linux was dependent on complicated plumbing that slows down the browser significantly.

So, that means you will have to provide me with a stack trace yourself if you want my help, because there is no tool that generates logs automatically upon application crash. But before we dive into the process of opening up Epyrus in GDB and start worrying about breakpoints, tell me if there's a file named "core" in the directory you use for Epyrus? If there is, send that to me because it means we got lucky and the program crashed in such a way as to produce a "naturally generated" stack trace that I can use to solve your problem. Otherwise, this will be a lot harder.

It might also help to set your directory to the Epyrus directory, and start Epyrus directly from a terminal window. Then try and reproduce your crash with Proton Bridge. If it crashes then, the core file should be in the current directory if one gets generated at all. If not, we're more likely to have to mess with GDB and that is not going to be fun.

Thank you to every one still willing to use Epyrus under these conditions. I know I am not providing the best user experience, but the fact of the matter is I'm not as experienced with this as Moonchild or Tobin. They've been doing this 10 years and are experts on release engineering and user support. I'm basically someone who knows how to get something to work on my system, and who isn't accustomed to making something polished that will work on other people's systems. So you'll have to bear with me stumbling around for a while if I am to make this application reliable. Or... use something else, of course. There's always webmail and Thunderbird.

[Giraffe]

Thank you for this.
I did it by unzipping to a folder that was named epyrus-1.1.0.win32, inside which was a folder named epyrus. I copied the total contents of that to the working folder, allowing override of all.
Epyrus wouldn't run, saying: "epyrus.exe - System Error
The program can't start because api-ms-win-core-libraryloader-l1-2-0.dll is missing from your computer. Try reinstalling the program to fix this problem."

Downloaded the .dll and put it into C:\Windows\System32. Now there was no response from the shortcut or epyrus.exe, even the newly downloaded one.
Obtained the previous version, went through copy/replace again - nothing. Renamed the working folder, copied the new epyrus 1.1.0 to Program files and away it went with all the settings intact.
So, working again but updating seems to be no-go for now.

Which version of this did you download? Was it the one labeled 1.1.0? If it was, that was actually already obsolete. I uploaded another after someone else had the problem before:

I believe I've solved the issue with the CRT not being distributed with the application. So, here's a quick redo of the Windows builds:

https://1drv.ms/u/s!AsscXELhr-eyh71QNDF ... g?e=y0auqx

If the new version is having the problem too, I would really like to know about it. I marked those builds 1.1.1 to differentiate them from the broken ones. There is the possibility that even with everything pointed to the right place, the package-manifest is out of date and not copying over all the files needed for the new compiler. In other words, the new version contains a whole bunch of files that start with "api-ms-win-core" that I forgot to distribute with the old one.

It seems like this is becoming a big problem very early in development... I posted a fix for the problem, but because the broken build was more visible, you probably downloaded that one instead. I really feel like I am in way over my head with trying to actually publish software. I'm in this awkward situation where multiple people have had the same problem, but I can't be sure if it's because they keep downloading a known broken build or because the new one still has the problem.

One thing I do want to commend you all for, though, is that it seems like every single person that had the problem figured out how to deal with the problem of missing CRT dll files. It was obviously inconvenient, but you all had enough of an idea of what was wrong to know how to fix it on your own. I guess we've all dealt with apps that fail to distribute that and had to download it at some point. It's just too bad my application is now one of them. LOL.

Apologies - I had d/l 1.1.1.win32.zip and it is that which gave the error message.
Fortunately 1.1.0 is still available from the link to it.

[athenian200]

Apologies - I had d/l 1.1.1.win32.zip and it is that which gave the error message.
Fortunately 1.1.0 is still available from the link to it.

But 1.1.0 shouldn't work better. That doesn't make any sense. That doesn't include the CRT at all.

Great. So my application is STILL broken and the seemingly obvious fix of shipping the CRT with it made things worse. :/

So as things stand now, the awkward solution of users downloading the CRT dlls themselves with 1.1.0 is the ONLY way this works, and the build that tries to fix that doesn't work at all?

I feel like my life is being eaten up by my lack of attention to detail and stupid little problems that would so easy for other people to solve. I really hate working on this. I feel like I get punished for not noticing every little detail of every stupid little thing with hours and days of wasted time and embarrassment as I have to sit around with a busted application that people want working. I hate my life. I hate release engineering, and I hate the challenge of making things work on systems I have no control over.

[distantpluto]

I feel like my life is being eaten up by my lack of attention to detail and stupid little problems that would so easy for other people to solve. I really hate working on this. I feel like I get punished for not noticing every little detail of every stupid little thing with hours and days of wasted time and embarrassment as I have to sit around with a busted application that people want working. I hate my life. I hate release engineering, and I hate the challenge of making things work on systems I have no control over.

I don't like to hear you talk like this. If I may comment... I think you need to step back and take a break from this. You're beating yourself up for no good reason, IMHO. It's beta, it's early and you're just doing us a massive favour just by providing what you have already

If it's any consolation, I've updated to 1.1.0 with no issues. Epyrus has been rock solid for me, be it on Linux, right from the start (we can forget my initial transfer of files issue ). I absolutely love Epyrus. Thank you and please take a well deserved break

[athenian200]

I don't like to hear you talk like this. If I may comment... I think you need to step back and take a break from this. You're beating yourself up for no good reason, IMHO. It's beta, it's early and you're just doing us a massive favour just by providing what you have already

If it's any consolation, I've updated to 1.1.0 with no issues. Epyrus has been rock solid for me, be it on Linux, right from the start (we can forget my initial transfer of files issue ). I absolutely love Epyrus. Thank you and please take a well deserved break

Well, I was kind of taking a break already because I knew once I did another release I was going to have to deal with a lot of stuff I didn't want to deal with. I was putting off dealing with it because I find making releases to be stressful in general. It's why it's been a couple months since the last one.

I like working on problems that are in front of me that I can solve. I don't like having to try and troubleshoot problems on other people's systems that I feel responsible for. I'm not really beating myself up, I'm just annoyed at how much time a problem that is probably very simple is taking up because it's not happening on my system right in front of me.

I will probably try to solve the CRT issue at least (I think I have a way to test that), but after that I probably won't do another release for a while. Maybe just focus on adding more to Epyrus and making it better for a while. It's weird, there's one part of the process I enjoy, solving problems on my own machine, but the release part... well, that's what I always dread and what usually doesn't work out for me.

[athenian200]

Well, I have good news and bad news. The good news is I managed to reproduce the issue, and if I fail to include the CRT, installing it from Microsoft as a redistributable works consistently to fix the problem. It's actually pretty tricky to realize... the version of Epyrus without the CRT worked on every version of Windows 10 I tried, even a fresh install. So it seems like it's only possible to reproduce the issue on Windows 7 (maybe 8 but I haven't tested yet), and even then I had trouble.

The reason is this... it seems like installing Skype or Microsoft Edge on older versions of Windows seems to cause the newer Visual Studio CRT to be installed by default, which means that I normally wouldn't see this issue even on a Windows 7 machine. Because those are the first two programs I usually setup after doing a new Windows install. So that's why, within my own little ecosystem of computers, I could never reproduce the issue with the original version.

The bad news is, trying to include the CRT and UCRT in the way that used to make installing that unnecessary breaks Epyrus in such a way that it cannot be fixed, even by installing the redist files. Giraffe's information checks out perfectly, and my test environment matches up with his observations. The weird thing is, the brokenness that results from including the CRT with the application is not reproducible on Windows 10. That is to say, bundling the same stuff that breaks it on Windows 7 causes no issues on a Windows 10 environment. So that's why I didn't notice it before shipping out. Building with the CRT/UCRT combo works fine on Windows 10.

The main issue seems to be this... the api-ms-win-core-libraryloader-l1-2-0.dll file doesn't exist in the SDK at all, so it can never be copied over. My working theory is that the newer version of libraryloader is actually a Windows component exclusive to newer Windows that for some reason gets linked against if and only if I opt to ship with the CRT. Even downloading that file as a random dll (and random dll seems to be the only source as it isn't in the SDK or shipped with the VC redist) did not solve anything and just produced an 0xc0000005 error.

Well, given these issues I can understand the reluctance to move to newer compilers for fear of breaking older Windows, but I am not satisfied with "use old tools forever" as a solution. This is just going to require a bit more creativity than I initially thought.

[athenian200]

Okay, it looks like I didn't miss an obvious detail, and that does make me feel a lot better about the situation. It was a lot trickier than I thought it was going to be.

I have new builds going as I speak, and the solution was rather involved. What I realized first while analyzing the dependencies that were leading to those library requests being made, and I noticed that Epyrus itself wasn't calling for any of these libraries. It was only the msvcp140.dll file bundled with the application that was calling for that stuff. I tried replacing the one I included with the one that the redist package installs to C:\Windows\System32... and the application worked.

What I eventually figured out was that there are two copies of msvcp140.dll that are very easy to get mixed up. There's one version that simply contains the CRT that I need, and another version that goes beyond including the CRT to including pointers to core Windows functions only found on newer versions of Windows. I had been including the wrong version with my application, while Microsoft's redist package included the correct one. So I did the build again with the correct version on a machine with no redistributable installed, and it still complained it was missing a new file called vcruntime140_1.dll. This file is part of the new runtime, simply didn't exist previously, and so our build system didn't include it. I added an asterisk wildcard to treat the entry for vcruntime140*.dll as more than one file to copy over to the final target. That seemed to be what was needed.

Suffice it to say, my application now seems to run on Windows 7 without a redist package.

EDIT: I tested these as thoroughly as I could, on Windows 7 and 8 without any redist installed. Hopefully this does the trick...

https://1drv.ms/u/s!AsscXELhr-eyh71kfY4 ... Q?e=UnBRwq

[distantpluto]

...I will probably try to solve the CRT issue at least (I think I have a way to test that), but after that I probably won't do another release for a while. Maybe just focus on adding more to Epyrus and making it better for a while. It's weird, there's one part of the process I enjoy, solving problems on my own machine, but the release part... well, that's what I always dread and what usually doesn't work out for me.

Those of us using Epyrus fully realise you're not some huge software corporation and you're one person filling a personal requirement who very graciously decided to share your work. Well I certainly do anyway. And as such you're under no obligation to anyone, other than to provide what you say you will. And you have and are doing so. You've stated the caveats and I use Epyrus under those conditions

I'm glad you got that issue sorted out.

[athenian200]

Those of us using Epyrus fully realise you're not some huge software corporation and you're one person filling a personal requirement who very graciously decided to share your work. Well I certainly do anyway. And as such you're under no obligation to anyone, other than to provide what you say you will. And you have and are doing so. You've stated the caveats and I use Epyrus under those conditions

I'm glad you got that issue sorted out.

Thank you, your understanding of that does mean a lot to me. Sometimes I forget that it isn't that kind of situation. But yeah, I would be very afraid to have someone deploy Epyrus in a corporate environment and, say, have a bunch of full-time employees depending on it. Or even to have someone who works from home rely on it as their only e-mail client and not have a backup plan in case something goes wrong with it. I mean, I would assume most people can grudgingly fall back to webmail and that using or not using it boils down to personal preference, but there might be someone relying on an Epyrus feature whose workflow would be disrupted by a bug.

[Moonchild]

But yeah, I would be very afraid to have someone deploy Epyrus in a corporate environment and, say, have a bunch of full-time employees depending on it.

Even if you're a professional with a team behind you, that kind of deployment is still nerve-wracking, so please don't feel bad about it.

Remember (everyone!) that all we do here is "best effort". If there's a problem, we'll work on solving it (which may take some patience). That is all we can promise. Something as complex as Epyrus or anything else that fulfils a very complex role will not be perfect out of the gate; expecting that to be so will make you fall into the trap of never releasing anything and chasing that perfection, and that simply doesn't help anyone.
Release engineering for a broad audience is hard. I've made plenty of mistakes in it myself (sometimes requiring me to recall and spend time making emergency releases to do my best for the users) but even those mistakes are not a disaster. Workflows get disrupted; it happens and is pretty much inevitable when changes are made or people swap to new software. There will always be people for whom an objective improvement will cause issues; there will always be situations you couldn't think of before they were presented to you by others.There is a reason we provide things in the hope they are useful, but don't give any guarantees beyond that we'll do our best. That goes for everything that's come out of here: Epyrus, Pale Moon, Basilisk, Ambassador, rebuilds for specific OS-es, etc.

Athenian, I think you can be a bit more confident than you seem to be in what you release; these kinds of hiccups aren't disasters, they are just hiccups in learning the release side of Mozilla-based software that will take some time to learn the quirks of (and the fact that hardly anything is documented doesn't help).