http://bugs.winehq.org/show_bug.cgi?id=2499
mstefani(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From mstefani(a)redhat.com 2004-12-10 15:44 -------
Latest CVS Wine works for me (tested it since sunday 20041010). I can go to the
bnet login screen, even updated Starcraft over that. And all without lock
up/crash of the X server.
My setup: FC2, nvidia driver, Gnome
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=1142
------- Additional Comments From wine(a)deesconsulting.com 2004-12-10 13:09 -------
Now lsof is telling me that Word XP doesn't obtain any lock on open documents.
This is with Crossover Office Pro 3.0.0.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2510
Summary: Error to execute dvd2one
Product: Wine
Version: unspecified
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P1
Component: wine-programs
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: javi.esteban(a)gmail.com
Good Afternoon,
I install today dvd2one with wine. All install correctly but when I try to
launch the problem show the next errors:
fixme:vxd:VXD_Open Unknown/unsupported VxD L"sice.vxd". Try setting Windows
version to 'nt40' or 'win31'.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"ntice.vxd". Try setting Windows
version to 'nt40' or 'win31'.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"siwvid.vxd". Try setting Windows
version to 'nt40' or 'win31'.
err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to
dispatch exception.
Please I need you help
Best Regards,
Javier
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=1142
------- Additional Comments From wine(a)deesconsulting.com 2004-12-10 12:10 -------
Upon further investigation, this is what I have found:
The main function for opening/creating files in Windows is NtCreateFile().
This function calls SERVER_START_REQ( create_file ) which tells the wine
server to open/create a file.
The function DECL_HANDLER(create_file) handles this request in the wine server
by calling the create_file() function.
create_file() calls open_fd().
open_fd() calls check_sharing().
check_sharing() seems to be the broken function in question. From a cursory
investigation, this function seems to only check for cached file locks within
the wine environment. check_sharing() does not call fcntl() to check for
filesystem locks in Linux. Thus, locks set by the wine server with lock_fd()
upon calling NtLockFile() are not checked upon file open.
Based on my previous post, I'm assuming that Windows normally enforces
mandatory file locking upon opening a file with NtCreateFile(). This
assumption could be wrong, but it explains the behaviour seen and seems to be
backed up.
Now the question becomes "what error/status should the wine server return to
the program upon opening a locked file?"
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2509
------- Additional Comments From jdaviestx(a)comcast.net 2004-12-10 09:24 -------
Created an attachment (id=701)
--> (http://bugs.winehq.org/attachment.cgi?id=701&action=view)
Source for the exe just submitted
If you have access to masm and would like to reproduce this bug in windows (I
wouldn't expect you to want to run an untrusted exe under windows), here's the
source I used to create this exe. Here is the "build script" I used:
ML.EXE -W0 -Zi -c -Fl -coff readcon.asm
LINK.EXE /PDB:NONE readcon.obj kernel32.lib user32.lib \
gdi32.lib /SUBSYSTEM:CONSOLE /DEBUG
And don't laugh at my assembler coding - I'm only at mid-terms in my class ;)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2509
------- Additional Comments From jdaviestx(a)comcast.net 2004-12-10 09:22 -------
Created an attachment (id=700)
--> (http://bugs.winehq.org/attachment.cgi?id=700&action=view)
Executable reproducing the problem
Here's an executable that reproduces the problem (obviously, you would only
want to run this "safe" in wineconsole). If I run this exe in windows, I see
the following output:
C:\masm32>readcon
Type a string: abcdef
8
However, under wineconsole, I see the following:
[jdavies@dhcp-347-6 masm]$ wineconsole readcon
Type a string: abcdef
7
It looks like windows is returning the length of the string, plus the CRLF
delimiters, whereas wineconsole is returning one less. I still can't figure
out how to debug into a masm assembler app under wine to figure out if wine is
just not translating the linux eol into a 0d0a, or if it's just dropping a
character from the count.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2509
Summary: ReadConsoleA returning wrong length
Product: Wine
Version: 20040914
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-console
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jdaviestx(a)comcast.net
I'm using Wine to run a really simple console application (part of a course I'm
taking on Assembler programming), and I've noticed that the following MASM code:
INVOKE ReadConsoleA,
consoleInHandle,
edx,
ecx,
OFFSET bytesRead,
0
(with, obviously, edx & ecx set to a buffer & its length, respectively) is
returning one less character in bytesRead than I actually typed. I'm trying to
wend my way through winedbg and figure this out myself, but if the gurus could
offer any assistance, I'd appreciate it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.