| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3438
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Unicode support |
|---|
| Summary: | using ASCII function when Unicode version is available (mingw-w64) |
|---|
| Version: | 1.3.4 |
|---|
| Created By: | dstarke |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | e4a972c3f3ab21549ad494a20517e1ec7fecce16 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | dstarke
07:11 Dec 02, 2017 |
| fl_system() and fl_execvp() assume that there is not _wsystem() or _wexecvp() available if the compile target defines __MINGW32__, falling back to their ASCII variant. mingw-w64 supports both function and defines __MINGW32__ and __MINGW64__. Attached is my proposed patch to use the UTF-16 version of both functions when compiling for mingw-w64. An additional way to solve this issue could be to try linking to the dll providing these functions in case of only __MINGW32__ being defined. For upstream support, the attached patch should be sufficient. | |
| |
| #2 | AlbrechtS
13:10 May 26, 2021 |
| Thanks for the report of this long-standing issue.
The (1.3) code has changed significantly in 1.4.x development and the fix is using a different approach but works (supposedly) with all supported Windows versions and compilers.
Closed w/resolution. | |
[ Return to Bugs & Features ]
|
| |
