Delta Chat Desktop on Windows Server 2008 R2

[konsta-n-tin]

• Platform (linux/mac/windows): Windows Server 2008 R2
• Delta Chat Desktop Version: 1.2.0
• Expected behavior: Start program when click on icon on desktop
• Actual behavior: Nothing happens
• Steps to reproduce the problem: Install Delta Chat Desktop Version 1.2.0 on Windows Server 2008 R2 and try to run
• Screenshots:
• Logs: Zero size logs in c:\Users\%username%\AppData\Local\DeltaChat\logs\

[konsta-n-tin]

Hmm... The same problem on Windows Server 2012 R2

[Jikstra]

Can you check out if you have the visual c++ runtime installed? Seems like this is sometimes the problem on windows:
#1323

Also can you start the .exe from the command line with the "--log-to-console --logLevel debug" arguments?

[konsta-n-tin]

Can you check out if you have the visual c++ runtime installed? Seems like this is sometimes the problem on windows:

It was helped me!
Thank you!

[the-Arioch]

Just stuck there with 1.3.4 on Win 8.1 x64
Installation of VC 2015 redist indeed helped.

---

More specific symptoms:

• TWO processes DeltaChat.exe are spawned.
• in AppData\Local a zero-length process-lock file created
• in AppData\Roaming an empty "accounts" folder created
• in AppData\Roaming a zero-length log-file is created

No any GUI !

After you kill those processes from Task Manager (and they are not easy to kill ! there is something i could not factor out, maybe one task keeps respawning another or some hard timeouts or something, it takes luck or persistence to make them finally die) the log files gets ONE message in it.

"2020-06-10T12:35:59.093Z"	"main/index"	"ERROR"	"\nprocess.<anonymous> (C:\\Users\\burov\\AppData\\Local\\Programs\\deltachat-desktop\\resources\\app.asar\\tsc-dist\\main\\index.js:40:9),\nprocess.emit (events.js:205:15),\nprocess._fatalException (internal/process/execution.js:146:25)"	"uncaughtError"	{"message":"The specified module could not be found.\r\n\\\\?\\C:\\Users\\burov\\AppData\\Local\\Programs\\deltachat-desktop\\resources\\app.asar.unpacked\\node_modules\\deltachat-node\\prebuilds\\win32-x64\\node.napi.node","stack":"Error: The specified module could not be found.\r\n\\\\?\\C:\\Users\\burov\\AppData\\Local\\Programs\\deltachat-desktop\\resources\\app.asar.unpacked\\node_modules\\deltachat-node\\prebuilds\\win32-x64\\node.napi.node\n    at process.func (electron/js2c/asar.js:138:31)\n    at process.func [as dlopen] (electron/js2c/asar.js:138:31)\n    at Object.Module._extensions..node (internal/modules/cjs/loader.js:828:18)\n    at Object.func (electron/js2c/asar.js:138:31)\n    at Object.func [as .node] (electron/js2c/asar.js:147:18)\n    at Module.load (internal/modules/cjs/loader.js:645:32)\n    at Function.Module._load (internal/modules/cjs/loader.js:560:12)\n    at Module.require (internal/modules/cjs/loader.js:685:19)\n    at require (internal/modules/cjs/helpers.js:16:16)\n    at load (C:\\Users\\burov\\AppData\\Local\\Programs\\deltachat-desktop\\resources\\app.asar\\node_modules\\node-gyp-build\\index.js:21:10)"}

Since you aim at making "novice-friendly" app this is truly wrong!
Creating no any user information is leaving newbs in empty dark room.

Frankly, to just call raw Windows GDI API no any overly-complex zillion-layers JS framework is required. DC has to have some plain watchdog inside the app that will alert user and save diagnostics if all the industry of virtual machines needed for cute GUI fails to start.

For instance, the moment log file is created seom stub info has already to be writting into it.
Like full path to EXE, version, maybe timetamp/size/md5 and URL of the project.
So if some admin or techie user finds there file somewhere - they know what it was about. Not some virus trace but a specific application happy to introduce itself.

And then i think there is some way to learn if Electron failed to start, even as dumb like just having a dormant thread waiting for 60 seconds for main app windows to arrive or something like that.
I can not give specific implementation advices, as i know nothing about Rust and Electron, but current behavior is just living user in the dark and cold... Actually, the thread in the 1323 shows it way too well...

---

And while we are at it, should TSV logs really have all those C string escapings? make them much harder to read.
I mean, sure, if you want to log into computer-centered format like XML or JSON or EDI - then you should conform to specs and order user to read format-specific viewers.
But if you want make non-techie human readable logs, then all those "xxxx\\xxx\\xxx" are merely making things hard for both reading/searching and copy-pasting into terminal or file manager.

[Simon-Laux]

In 1.4 the logs will have less strings escaped and some padding to be easier human readable #1650
I think its not electron that fails to start, rather it's the node bindings for our core that fail due to the missing Visual c++ redist thingie.
Anyway we'll probably try to fix that when releasing 1.4 which is the next upcoming release.

[Simon-Laux]

https://stackoverflow.com/questions/35097193/can-i-bundle-the-visual-studio-2015-c-redistributable-dlls-with-my-applicatio

looks like its ok for ms when we bundle the files, now I only need to find a good way to get them and to bundle them... time to spin up a windows vm

[Simon-Laux]

another option would be to modify the building of the core for the node bindings: https://www.reddit.com/r/rust/comments/7mif9i/how_to_compile_binaries_without_dependencies_on/
That sounds better because this could fix the node binding prebuilds on systems that don't have the vc redist installed (if the issue is there, I don't know if it is)

Update 1:
so -Ctarget-feature=+crt-static seems to only apply to binaries, not libraries, at least that is what I'm reading on multiple places.

neon-bindings/neon#519 looks related, currently I'm not really understanding the comment what needs to be done there, so lets keep this link here, maybe we need it later again.

[Simon-Laux]

Copying all the dll files of the redist to the deltachat instalation folder solved the issue, now I only need to change the build process to do that.

[Simon-Laux]

Hey folks, I have a portable version for you to test https://testrun.org/DeltaChat%201.4.0.testing.exe
It works for me on my windows vm, but I want to know if it works for you too.

[the-Arioch]

Copying all the dll files of the redist to the deltachat instalation

....comparing DeltaChat footprint with VisualIRC footprint, "well, d'oh..."

As for test, my win box is not tainted with VC++ runtime, but will i have a clean windows box i will try

[Simon-Laux]

@the-Arioch yeah electron is heavy, though the msvc thing is actually required to run the deltachat core on windows, and that has nothing to do with electron.
There were two options left (unless there are more that I missed):

• Bundle the vcredist installer with our installer, but that doesn't solve the problem for the portable version.
• bundle the relevant files (aka. local deployment)

the 1,7mb more are not that much considering the electron footprint and we can still save some space by excluding more useless unused files from the final package.

[hpk42]

The apk is also >50MB so 70MB is not that bad. Really excited to get a "just installs" DC Desktop version for windows -- a major milestone ;)

…

On Tue, Jun 23, 2020 at 03:36 -0700, Simon Laux wrote: @the-Arioch yeah electron is heavy, though the msvc thing is actually required to run the deltachat core on windows. There were two options left (unless there are more that I missed): - Bundle the vcredist installer with our installer, but that doesn't solve the problem for the portable version. - bundle the relevant files (aka. local deployment) 1,7mb more are not that much considering the electron footprint and we can still save some space by excluding more useless unused files from the final package. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #1597 (comment)