http://bugs.winehq.org/show_bug.cgi?id=12006
Summary: ForceBindIP crashes
Product: Wine
Version: 0.9.56.
Platform: Other
URL: http://www.r1ch.net/stuff/forcebindip/
OS/Version: other
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
In http://www.winehq.org/pipermail/wine-users/2008-March/029930.html
maci at satgnu.net writes:
" ForceBindIP http://www.r1ch.net/stuff/forcebindip/ does exactly what i need.
unfortunally it doesnt work in wine"
In a later message he said
--- snip ---
$ wine ForceBindIP.exe 10.0.0.10 "C:\\SCBW\StarCraft.exe"
fixme:spoolsv:serv_main (0 (nil))
err:ntdll:RtlpWaitForCriticalSection section 0x7efec884 "loader.c:
loader_section" wait timed out in thread 0012, blocked by 0011, retrying (60
sec)
wine: Critical section 7efec884 wait failed at address 0x7ef96f90 (thread
0012), starting debugger...
Unhandled exception: wait failed on critical section 0x7efec884 loader_section
No process loaded, cannot execute 'echo Modules:'
--- snip ---
and
--- snip ---
$ wine ForceBindIP.exe -i 10.0.0.10 "C:\\SCBW\StarCraft.exe"
fixme:spoolsv:serv_main (0 (nil))
fixme:advapi:SetSecurityInfo stub
Unhandled exception: page fault on write access to 0x81fffcc8 in 32-bit code
(0x7ee68c50).
Backtrace:
=>1 0x7ee68c50 LocalReAlloc16+0x10() in kernel32 (0x7d44da28)
2 0x7efc6852 call_thread_func+0x42() in ntdll (0x7d44dac8)
3 0x7efc6aef in ntdll (+0x56aef) (0x7d44e3c8)
4 0xb7e9e162 start_thread+0xd2() in libpthread.so.0 (0x7d44e4b8)
--- snip ---
--
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=24306
Summary: kernel/console: no more EOF handling.
Product: Wine
Version: 1.3.2
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineserver
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
CC: eric.pouech(a)orange.fr
Hi,
^D (^Z in native) used to be able to end the session with my
interactive MCI shell (bug #20232, comment #9). What it does is:
HANDLE hin = GetStdHandle(STD_INPUT_HANDLE);
ret = ReadFile(hin, inbuf, sizeof(inbuf)/sizeof(inbuf[0])-1,
&received, NULL);
if(!ret || !received) break;
^D signals EOF in UNIX (more precisely, it immediately returns the
pending read(), which is interpreted as EOF when there is no more
input on the line). ^Z is EOF in MS-Windows, since MS-DOS times.
Presumably since Eric Pouech's console patches, EOF is not recognized
and I must ^C the program.
BTW, native's ^Z handling differs among versions. In win95, ^Z
immediately sends an EOF to the app; since w2k you need ^Z + Return.
^Z is not honoured in Wine (after using "stty susp ^y").
Alternatively instead of wine mcishell.exe,
using ^C in an mcishell started inside "wine cmd" yields:
^Cfixme:console:CONSOLE_DefaultHandler Terminating process 8 on event 0
fixme:console:CONSOLE_DefaultHandler Terminating process 1c on event 0
err:console:WCEL_Get hmm bad situation
mci.c:1376hoehle:~/Bugs$ : GetLastError: 0 <= that's from mcishell,
so it was not aborted!?!
^^^^^^^^^^^^^^ bash prompt gets in between
mcishell: 2 tests executed (0 marked as todo, 1 fai <= nothing more
I just noticed console error #2:
wine wineconsole cmd (as the usage() text says)
opens a virtual desktop but no console window appears.
That desktop window cannot be activated.
Clicking the close button produces Wine's "kill app" requester after a couple
of seconds. Accepting yields a mini backtrace in the terminal:
0x9d50fd0:1: Fd unix_fd=71 user=0x9db3320 options=00000020
0x9db3320:1: Console screen buffer input=0x9d53fe0
0x9d50f10:1: Fd unix_fd=65 user=0x9d53fe0 options=00000020
0x9d598a0:1: Event manual=1 signaled=0 name=""
0x9d53fe0:1: Console input active=0x9db3320 evt=(nil)
That does not look like a typical backtrace from Wine.
Ah, it's from server/{event,console}.c
I should probably open a separate bug report for that one.
I'm using Ubuntu Intrepid.
--
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=23975
Summary: mcicda wants to open the nth cdrom in the system
Product: Wine
Version: 20020228
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winmm&mci
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
CC: eric.pouech(a)orange.fr
Eric,
I wanted to query you about the change you introduced 2002-01-13.
As the subject says, MCI_Open opens the nth drive of type CD-ROM,
where N is the dwDeviceID passed to the command.
Currently Wine passes in the device ID that will be used if Open succeeds, i.e.
the number of open MCI devices (I believe it was 0 at some time in the past).
Therefore
open cdaudio alias c will work, while
open new type waveaudio alias w
open avivideo alias a
open cdaudio alias e
will likely fail in Wine, unless you have 3 CD-ROMs.
This is a bug. It works in native.
I found no documentation for this N thing in MSDN. Where does it come from?
My own testing -- as far as it can go with a single drive -- suggests
that there's no such functionality in native. Quite to the contrary,
using SHAREABLE, I could open a device multiple times using
mciSendCommand(N>0, MCI_OPEN,
MCI_OPEN_TYPE|MCI_OPEN_TYPE_ID | MCI_OPEN_SHAREABLE,
(DWORD_PTR)&parm);
(Not using SHAREABLE seems to reveal an interesting bug in native for N>0).
OTOH, perhaps this functionality exists in the driver, i.e. not accessible at
the level of mciSendCommand and the bug is in Wine's MCI that does not pass a 0
as default id (it should pass 0 and stuff the new ID in openparms.wDeviceID)?
BTW, you may be interested by the mcicda patches I recently submitted.
Regards,
Jörg Höhle.
--
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=16241
Summary: Call of duty 5 World at War : Fails to initialize
Product: Wine
Version: 1.1.9
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: xvachon(a)gmail.com
Created an attachment (id=17502)
--> (http://bugs.winehq.org/attachment.cgi?id=17502)
+seh report
Contrarily to the test report, my installation went flawless. When I launch the
game, I get an unhandled exception. After the first attempt I installed DX9 and
the Offscreenrenderingmode, directdrawrenderer and videomemorysize registry
keys, the result remains the same. I have attached a +seh output. Should you
need more, tell me.
--
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=24400
Summary: Sims 3 crashes at startup with unimplemented function
msvcr80.dll._atoflt
Product: Wine
Version: 1.3.2
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
I'm trying to see if I can get The Sims 3 running with no microsoft code.
Skipping the launcher and running TS3.EXE directly, the first crash is
wine: Call from 0x7b837db2 to unimplemented function
msvcr80.dll._set_abort_behavior, aborting
Work around that with the hack attached to bug 23394.
The app then crashes with
wine: Call from 0x7b837db2 to unimplemented function msvcr80.dll._atoflt,
aborting
--
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=20314
Summary: wine loader doesn't work on Debian/kFreeBSD
Product: Wine
Version: 1.1.31
Platform: PC
URL: http://www.debian.org/ports/kfreebsd-gnu/
OS/Version: FreeBSD
Status: NEW
Keywords: download, source
Severity: critical
Priority: P2
Component: loader
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Found out about the debian/FreeBSD port, so I gave it a spin. Wine mostly
compiles, with a couple warnings (I'll send a patch in a bit), but the killer
is loader/preloader.c. It's disabled on FreeBSD normally, by configure.ac:
case $host_cpu in
*i[[3456789]]86*)
case $host_os in
linux* | k*bsd*-gnu)
AC_SUBST(EXTRA_BINARIES,"wine-preloader") ;;
esac
;;
esac
but the k*bsd*-gnu enables it here. The problem is, preloader.c has some linux
specific stuff:
static inline int wld_prctl( int code, int arg )
{
int ret;
__asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx"
: "=a" (ret) : "0" (SYS_prctl), "r" (code), "c" (arg)
);
return SYSCALL_RET(ret);
}
The SYS_prctl is Linux specific, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550435
I tried removing the k*bsd*-gnu from configure.ac, but the loader still doesn't
work:
wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: failed to map
segment from shared object: Cannot allocate memory
--
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=23223
Summary: Cyberboard Player: unwind menu disappear when clicked
Product: Wine
Version: 1.2-rc3
Platform: x86
URL: http://cyberboard.brainiac.com/cyberboardv310.exe
OS/Version: Linux
Status: UNCONFIRMED
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: wylda(a)volny.cz
Created an attachment (id=28900)
--> (http://bugs.winehq.org/attachment.cgi?id=28900)
Screenshot showing the menu
Attachment shows the menu i'm talking about. When you run the app by "wine
CBPlay.exe" the menu works as expected, i.e. when you click, menu keeps up.
Now, when "File" -> "Open" -> "GenericGame.gam" the menu stops working, i.e.
when you click, menu shows up only for fraction of the second and then
disappears.
I tried many wine versions sice 0.9.49 till 1.2-rc3, but it probably never
worked correctly.
I left this in UNCONFIRMED, but someones confirmation is welcomed ;)
--
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=15423
Summary: mIRC enters deadlock after a second playback attempt
Product: Wine
Version: CVS/GIT
Platform: PC
URL: http://www.mirc.com/get.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winmm&mci
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: nodisgod(a)yahoo.com
Created an attachment (id=16285)
--> (http://bugs.winehq.org/attachment.cgi?id=16285)
mIRC thread backtrace
With current Git (wine-1.1.5-207-gc425c8a), when using the splay mIRC command
to play back a WAV file, the first playback attempt succeeds, but a second
attempt causes mIRC to lose all responsiveness. A bit of investigation seemed
to indicate that the first playback thread blocks inside WAVE_mciPlayWaitDone()
in line 853 of dlls/mciwave/mciwave.c after exiting the playback loop:
WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */
which does not allow the code after it to run. When mIRC tries to close the
device, it ends up waiting on
while (wmw->dwStatus != MCI_MODE_STOP)
Sleep(10);
in WAVE_mciStop() in the process of closing the device, thus resulting in a
deadlock. Removing the line in mciwave.c eliminates the deadlock, although the
resulting mciwave behavior when attempting to play back another stream in mIRC
while a stream is playing does not match the behavior on Windows. Backtraces
and winmm/mciwave traces are attached.
--
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=12004
Summary: foobar2000-0.9.4.4 toolbars not adjustable/moveable
Product: Wine
Version: 0.9.57.
Platform: PC
URL: http://www.foobar2000.org
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: h.judt(a)gmx.at
This is version specific to wine-0.9.57. It does not occur with <=0.9.55 (but I
think I saw this using much older versions, so it might be a regression).
Toolbars cannot be adjusted in size or position or placed beside each other.
They cannot be not dragged to another place, though the mouse cursor changes
appropriately to indicate this would be possible.
--
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.