Slic3r does not start (crashes) on Windows, when installed in a localized directory

[lonelymyp]

Version

1.33.4 x32/64

Operating system type + version

W8 x64

Behavior

Сrash at startup If the program is running from the disk D, from disk С run without problems

[bubnikv]

@lonelymyp What is the full path of your folder, where you unpacked slic3r on the D: drive?
Does it crash if you unpack it directly to d:\ ?

[lonelymyp]

D:\Slic3r\slic3r.exe - Ok
D:\Users\Фёдор\Downloads\Slic3r-1.33.4-prusa3d-win32-full-201702151702\Slic3r-1.33.4\slic3r.exe - crash

[bubnikv]

All right, Фёдор, I think this is the issue.

Slic3r is written in C++ & Perl, Perl does not fully support Unicode access (yes, in year 2017) to Windows file system.

What Windows localization is it? Was it been installed as English, or Russian (maybe Bulgarian :-) ) Windows? Is your name written with the code page, which is default to your Windows installation? Sorry, I know these are very technical questions.

[burbilog]

Yeah, that's how Russian Windows works. I'd say 95% of Windows installations in Russia are using cyrillic names in paths and that's a huge pain in the ass with many non-unicode-aware programs. Windows installer ask for user's name and people enter their name, even Russian language is pre-selected.

[bubnikv]

I am Czech, when installing Slic3r into a nicely named folder
D:\temp\ščéířáýěščíéřýáěščé\Slic3r-1.33.4-prusa3d-win64-full-201702151702
it crashes as well. Something to look into.

[bubnikv]

There seems to be something bad going on with Perl & WxWidgets. I am not sure whether I will be able to fix this issue any time soon.

[bubnikv]

@lordofhyphens FYI, this is another surprise of wxPerl.

[bubnikv]

I sent an e-mail to [email protected]
but I don't expect this problem to be fixed any time soon. I think my time is better invested working on slicing algorithms and on getting rid of Perl than on fixing an abandoned wxPerl.

[CReimer]

Getting rid of Perl sounds nice. I already tried to remove most of Build.pl stuff, but Perl doesn't make it easy to build a Perl module outside of their weird Module::Build environment.

[bubnikv]

It seems the perl itself is broken and the core perl dynaloader fails to work, if the perl was started with long names. For example, running slic3r with the following slic3r.bat fails:

"%~dp0\perl5.24.0.exe" "%~dp0\slic3r.pl" %*

It works though, if one replaces the magic %~dp0 with %~dps0:

"%~dps0\perl5.24.0.exe" "%~dps0\slic3r.pl" %*

That way both the paths of the perl.exe and slic3r.pl use the 8.3 characters only per directory entry.

[lordofhyphens]

I am working on a C++ port of the GUI for main branch. "Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

…

On Thu, Feb 16, 2017 at 11:15 AM, bubnikv ***@***.***> wrote: It seems the perl itself is broken and the core perl dynaloader fails to work, if the perl was started with long names. For example, running slic3r with the following slic3r.bat fails: "%~dp0\perl5.24.0.exe" "%~dp0\slic3r.pl" %* It works though, if one replaces the magic %~dp0 with %~dps0: "%~dps0\perl5.24.0.exe" "%~dps0\slic3r.pl" %* That way both the paths of the perl.exe and slic3r.pl use the 8.3 characters only per directory entry. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#133 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB8Cm4gb-6CVtOchq7ERblogEitybF4ks5rdIQcgaJpZM4MCqXF> .

[bubnikv]

Fixed by executing perl and setting the library paths to short (8.3) paths.
The slic3r.exe has been modified to execute the perl interpreter with 8.3 paths if started from a directory with non-ISO characters, and an information is printed out to a console in such a case. If slic3r is installed in a directory with ISO characters only (and without spaces and semi-colons), the long path is used as before.