https://bugs.winehq.org/show_bug.cgi?id=47766
Bug ID: 47766
Summary: PathAllocCanonicalize treats path segments start with
dots wrong.
Product: Wine
Version: 4.16
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernelbase
Assignee: wine-bugs(a)winehq.org
Reporter: zzhang(a)codeweavers.com
Distribution: ---
This bug was reported on wine-devel mail list by Sebastian M. Ernst
<ernst(a)pleiszenburg.de>
user@comp:/path/other> WINEDEBUG=-all PYTHONHOME="z:\\path\\.to\\target"
wine /path/.to/target/python.exe -c "import sys; print(sys.executable)"
Z:\pathto\target\python.exe
PYTHONHOME="z:\\path\\..to\\target" wine /path/..to/target/python.exe -c
"import sys; print(sys.executable)"
Z:\to\target\python.exe
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48542
Bug ID: 48542
Summary: Mono (and probably .NET) needs CreateThreadpoolIo
Product: Wine
Version: 5.0
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernelbase
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Distribution: ---
Found testing LiveSplit 1.7.7 on Wine Mono from the master branch.
Mono's implementation of System.Threading.ThreadPoolBoundHandle depends on
CreateThreadpoolIo. Wine's stub of this function returns 0 and doesn't set last
error, resulting in the confusing message "System.IO.IOException: Success".
This can be more easily reproduced by running 'make test' in Wine Mono and
running tests/run-tests.exe
MonoTests.System.IO.Pipes.PipeSecurityTest:NamedPipePermissionsActuallyWorkAsync
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48471
Bug ID: 48471
Summary: Mismatching behavior of GetEnvironmentVariableW for
empty / long values
Product: Wine
Version: 5.0-rc4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernelbase
Assignee: wine-bugs(a)winehq.org
Reporter: wine(a)thecybershadow.net
Distribution: ---
Attempting to build the Windows version of DMD, the reference compiler for the
D programming language, fails under Wine. This seems to be caused by the
following chain of events:
1. The makefile invokes a build program with a "VERBOSE=" on the command-line:
https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/…
(Here "$(VERBOSE)" is not set and expands to the empty string.)
2. The build program registers the command-line arguments into the process
environment:
https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/…
This sets the environment variable VERBOSE to the empty string.
3. Later, it attempts to check if the "VERBOSE" variable is in the environment:
https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/…
4. This calls the following Windows code in the standard library to read the
environment:
https://github.com/dlang/phobos/blob/e373b4e77448bc11c6e4ea6c85bcdb8f7ab86f…
5. For empty variables, the code behaves differently in Windows and Wine -
Wine's implementation returns 0, while Windows returns 1. As a result, the
standard library code throws an exception under Wine.
Writing a test program reveals further differences. The program:
#include <stdio.h>
#include <windows.h>
void main()
{
WCHAR buf[4];
DWORD size;
int len, i;
for (len = 0; len <= 2; len++)
{
for (i = 0; i < len; i++)
buf[i] = 'a';
buf[len] = 0;
SetEnvironmentVariableW(L"TESTVAR", buf);
for (i = 0; i <= len + 1; i++)
{
DWORD err;
SetLastError(1);
buf[0] = 1;
size = GetEnvironmentVariableW(L"TESTVAR", buf, i);
err = GetLastError();
printf("%d->%d: size=%d error=%d buf[0]=%d\n",
len, i, size, err, buf[0]);
}
printf("\n");
}
}
Output on Windows [Version 10.0.17134.648]:
0->0: size=1 error=1 buf[0]=1
0->1: size=0 error=1 buf[0]=0
1->0: size=2 error=1 buf[0]=1
1->1: size=2 error=1 buf[0]=0
1->2: size=1 error=1 buf[0]=97
2->0: size=3 error=1 buf[0]=1
2->1: size=3 error=1 buf[0]=0
2->2: size=3 error=1 buf[0]=0
2->3: size=2 error=1 buf[0]=97
Output on Wine:
0->0: size=0 error=1 buf[0]=1
0->1: size=0 error=1 buf[0]=0
1->0: size=2 error=122 buf[0]=1
1->1: size=2 error=122 buf[0]=1
1->2: size=1 error=1 buf[0]=97
2->0: size=3 error=122 buf[0]=1
2->1: size=3 error=122 buf[0]=1
2->2: size=3 error=122 buf[0]=1
2->3: size=2 error=1 buf[0]=97
We can observe these differences:
1. Wine returns 0 and not 1 when the variable is empty and the function is
given a zero-length buffer.
2. Wine sets the last error to ERROR_INSUFFICIENT_BUFFER, while Windows
doesn't.
3. Windows zeroes the buffer if the size is non-zero but still insufficient to
hold the value. (This is not a bug as the behavior is specified in the
documentation to be undefined.)
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33317
Bug #: 33317
Summary: Python error Fatal Python error: buffer overflow in
getpathp.c's joinpath() when executing.
Product: Wine
Version: unspecified
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: andrew.thomas(a)hpcwales.co.uk
Classification: Unclassified
Created attachment 44067
--> http://bugs.winehq.org/attachment.cgi?id=44067
Lwsn output from running under wine
Wine Version : wine64 --version
wine-1.5.25
(64 Bit version)
GCC Version : gcc --version
gcc (GCC) 4.6.2
Python Version : python --version
Python 2.7.3
Operating Systems Used:
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
I have also tried on :
cat /etc/redhat-release
CentOS release 5.5 (Final)
Program trying to run lwsn.exe (network render module part of Lightwave :
https://www.lightwave3d.com/ ). 30 Day trial available.
Command used:
wine lwsn.exe -3 -cLWEXT11-64.CFG -d"z:\home\andy.thomas\Atticus"
Scenes\black.lws 1 1
Problem,
I compiled wine and setup lwsn.exe in accordance with this article:
http://lordtangent.blogspot.co.uk/2007/01/running-lightwave-screamernet-lws…
Initially it worked fine when running from the command line. I then wrapped it
up in a batch script to be sent to our Linux cluster but got a Python error
message :
Fatal Python error: buffer overflow in getpathp.c's joinpath()
I tried to execute interactively on the cluster and this worked fine but when
executed from a script it gives the above error.
I launched a forum post (as I a haven't done much troubleshooting with wine) :
http://forum.winehq.org/viewtopic.php?f=8&t=18632
I have tried the recommendations but had no success.
I re-compiled wine with the above gcc compiler and a more up to date version of
Python but I can no longer execute on the command line. I now get the Python
error regardless of how I execute the command.
Any help would be greatly appreciated. If you need any further debugging please
let me know.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17124
Summary: MSYS installer doesn't pop up cmd window?
Product: Wine
Version: 1.1.13
Platform: Other
URL: http://www.mingw.org/wiki/msys
OS/Version: other
Status: NEW
Keywords: download, Installer, source
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
When install msys, it floods the terminal with:
This is a post install process that will try to normalize betweenyour MinGW
install if any as well as your previous MSYS installs if any. I don't have any
traps as aborts will not hurt anything.Do you wish to continue with the post
install? [yn ] pi.sh: [: ==: unary operator expectedDo you have MinGW
installed? [yn ] pi.sh: [: ==: unary operator expectedWhen you install MinGW I
suggest you install it to C:/mingw(replace C: with the drive of your choice).
Then create an/etc/fstab file with a line that has a value similar to:C:/mingw
/mingwPress ENTER to continue Normalizing your MSYS environment.You
have script /bin/awkYou have script /bin/cmdYou have script /bin/echoYou have
script /bin/egrepYou have script /bin/exYou have script /bin/fgrepYou have
script /bin/printfYou have script /bin/pwdYou have script /bin/rviYou have
script /bin/rviewYou have script /bin/rvimYou have script /bin/viYou have
script /bin/viewMinGW-1.1 has a version of make.exe within it's bin/
directory.Please be sure to rename this file to mingw32-make.exe once youve
echo installed MinGW-1.1 because it\s very deficient in function.Press ENTER to
continue.C:\msys\1.0\postinstall>pause
Press Return key to continue:
Towards the end. It looks like something that should be in a cmd prompt
(haven't tested on windows yet). The line endings are also wrong, but that's
another bug.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42474
Bug ID: 42474
Summary: unimplemented function
api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx
Product: Wine
Version: 2.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: api-ms-win-*
Assignee: wine-bugs(a)winehq.org
Reporter: anonymous.maarten(a)gmail.com
Distribution: ---
Hey,
python 3.6 (32- and 64-bit) needs the unimplemented function
api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx
URL:
https://www.python.org/ftp/python/3.6.0/python-3.6.0-embed-amd64.zip
$ du -b python-3.6.0-embed-amd64.zip
6925798 python-3.6.0-embed-amd64.zip
$ shasum python-3.6.0-embed-amd64.zip
37bf20dcf39dfca096b11d29865202229a8fcb42 python-3.6.0-embed-amd64.zip
$ wine --version
wine-2.0 (Staging)
Running Fedora 24
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48288
Bug ID: 48288
Summary: kernelbase: Japanese character wrongly reported as
invalid.
Product: Wine
Version: 5.0-rc1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernelbase
Assignee: wine-bugs(a)winehq.org
Reporter: sagawa.aki+winebugs(a)gmail.com
Regression SHA1: 7e8f1dac30267058cf3b36d49b6ed3c440087024
Distribution: Ubuntu
Wine 5.0-rc1 has an issue which is very similar to Bug 17500.
I'm working on this and I'll submit a parch in a few days.
In short, the following code doesn't work as expected:
MultiByteToWideChar(932, MB_ERR_INVALID_CHARS, "\x81\x45", -1, NULL, 0);
Steps to reproduce:
1. obtain the test case from attachment 19616 (written by Leffe for Bug
17500).
2. compile it with mingw32 compiler.
3. LANG=ja_JP.UTF-8 wine testcase.exe
4. echo "ret is $?"
Expected result:
ret is 0
i.e. MultiByteToWideChar doesn't report an error.
Actual result:
ret is 1
i.e. MultiByteToWideChar complains about the input.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47649
Bug ID: 47649
Summary: Wavelab 6 Installs but cannot launch
Product: Wine
Version: 4.14
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shagooserver(a)gmail.com
Distribution: ---
Created attachment 65087
--> https://bugs.winehq.org/attachment.cgi?id=65087
wavelab 6 error report
Program installs but upon launch throws out an error, also produces a report to
submit with bug report which is attached.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.