http://bugs.winehq.org/show_bug.cgi?id=6941
--- Comment #15 from Bruno Jesus <00cpxxx(a)gmail.com> ---
I have seen this problem before. Thread 1 is waiting in recvfrom while Thread 2
closes the socket. Thread 1 never resumes recvfrom and hangs forever.
--
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=19320
Summary: space in-between of two different links gets removed
in "description" field if it not part of any link
Product: WineHQ Apps Database
Version: unspecified
Platform: PC
URL: http://appdb.winehq.org/objectManager.php?sClass=appli
cation
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: virtuousfox(a)gmail.com
i was trying to edit application's "description" field and then i have commited
changes space in-between of two separate links got removed
see http://appdb.winehq.org/objectManager.php?sClass=application&iId=4640
--
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=34282
Bug #: 34282
Summary: AppDB App for Wine
Product: WineHQ Apps Database
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: shatteredlites(a)gmail.com
Classification: Unclassified
Ok It just came to mind that there should be a app for wine that keeps track of
the AppDB and its games and this is my Idea and what it could do...
When wine is running you will be asked whether or not to send info as in- game
logs and debug info and system info without compromising privacy that is. and
while this app runs it would do a search in AppDB on what game you're using and
what settings are recommended for it as well as patches for it and so on. The
info that is being sent while ingame can be monitored by the game maintainer in
Appdb to check for bugs or regressions.
what do yall think and how would I go about asking for an enhancement like
this?
EXTRA INFO
Requirements To Work
-AppDB Game Needs A Maintainer
-AppDB Games Need Constant Watch To Keep Track Of Regressions & Bugs
Pros & Cons
Pro- Games Will Automatically Apply Fixes When Needed
Pro- Bugs Could Automatically Be Sent To Bugzilla With Info Already In Report
Pro- Less Hassle For Devs & Users
Con- More Dedicated Devs Needed To Keep DB In Order
Con- A New Project That Will Take Time
Con- WineHQ Will Go Through Changes In Order To Work With Program
--
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=6941
--- Comment #14 from Bruno Jesus <00cpxxx(a)gmail.com> ---
Still in wine 1.7.9. It blocks in a recv call in an IPX socket, I'll try to
find out what is happening when I have time.
--
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=23940
Summary: SetWindowPos does not work for other wine processes
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jUrner(a)arcor.de
resizing windows belonging to other (wine) processes does not work. user32.dll
SetWindowPos() always returns 0.
somewhere down in winpos.c set_window_pos() returns FALSE
wine 1.2
--
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=5402
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|patch |
URL|http://www.wolflair.com/rig |http://www.minisiteg.narod.
|htframe.php?context=army_bu |ru/Canon/PhotoStitch311332.
|ilder&page=downloads |rar
Summary|Multiple apps crash (e.g. |Canon PhotoStitch 3.1.13
|PhotoStitch 3.1, Army |crashes on startup
|Builder, Web Builder....) |
--- Comment #37 from Anastasius Focht <focht(a)gmx.net> ---
Hello folks,
still present.
--- snip ---
...
0009:Ret user32.CreateWindowExA() retval=00010076 ret=5f40c211
0009:Call user32.GetActiveWindow() ret=5f4013c8
0009:Ret user32.GetActiveWindow() retval=00000000 ret=5f4013c8
0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x42e81e ip=0042e81e
tid=0009
0009:trace:seh:raise_exception info[0]=00000000
0009:trace:seh:raise_exception info[1]=00000138
0009:trace:seh:raise_exception eax=00000000 ebx=0033e24c ecx=0033e20c
edx=00000386 esi=0019e6d0 edi=0019e3f8
0009:trace:seh:raise_exception ebp=00000000 esp=0033e1f4 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010246
--- snip ---
ArmyBuilder 3.1 (http://www.wolflair.com/download/ab/ab31c_install.exe) also
referenced in this bug works fine which indicates it suffered from bug 19052
'WYSIWYG Web Builder 5.5.x' (http://3dwebdesign.org/download/webbuilder5.zip)
also works fine indicating it suffered from bug 19052
Refining summary and replacing download with old version of PhotoStitch 3.1.13
$ sha1sum PhotoStitch311332.rar
02856a422d6d57eb2c6694463f422852a7c653e5 PhotoStitch311332.rar
$ du -sh PhotoStitch311332.rar
4.0M PhotoStitch311332.rar
$ wine --version
wine-1.7.9-158-g33fa552
Regards
--
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=2082
--- Comment #128 from Vincent Povirk <madewokherd(a)gmail.com> ---
> The ultimate result is that dialog D obscures window A. I haven't
> investigated why dialog D is all black as opposed to looking like a typical
> user32 dialog window with controls.
This is because (on Windows, at least before compositing was introduced and
before Windows 8), although ddraw will ignore clipping and draw over other
windows, it does not prevent those other windows from also drawing. To prevent
ddraw from fighting user32 and causing flicker, WA intentionally prevents the
dialog from drawing (on older versions that prevention was flawed and you'd
sometimes get flicker anyway, but they may have fixed that). It happens that WA
does not need to do any gdi drawing at all, but other programs use clipping to
mix ddraw with gdi, and there may be a few that do not use clipping but instead
manually synchronize ddraw and gdi drawing (diablo maybe?).
--
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=2082
Stefan Dösinger <stefan(a)codeweavers.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stefan(a)codeweavers.com
--- Comment #127 from Stefan Dösinger <stefan(a)codeweavers.com> ---
d3d8/9 drawing to the desktop window is not valid, unless D3DDEVTYPE_NULLREF is
used. Which is what some applications do, and we don't implement NULLREF and
just treat it as HAL.
I believe we have tests that demonstrate that opengl rendering on the desktop
window is not valid on Windows. I might be mistaken though, I haven't checked
the code.
I'm not entirely sure about the ddraw behavior. This needs some additional
tests for clippers. Specifically we'll have to check what clippers do in
fullscreen mode, and if clippers affect primary surface locks (and not just
blits). The current behavior is to render to the clipper window if a clipper is
assigned to the primary, and it has a clip window and not a clip list.
What may be the correct behavior:
*) Always render to the device window, which is NULL by default unless the
application explicitly sets it with SetCoopLevel(DDSCL_SETDEVICEWINDOW) or asks
ddraw to create one with SetCoopLevel(DDSCL_CREATEDEVICEWINDOW). I think
SetCoopLevel(window, FULLSCREEN | EXCLUSIVE) just sets the focus window, not
the device window.
*) Never render to the clipper window.
*) Use the clipper window only in surface::blt to limit the written area.
--
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=2082
--- Comment #126 from Ken Thomases <ken(a)codeweavers.com> ---
Created attachment 46977
--> http://bugs.winehq.org/attachment.cgi?id=46977
Use desktop window for fullscreen ddraw, with support in Mac driver
This is a hack that a) makes ddraw target the desktop window when
DDSCL_FULLSCREEN is specified and doesn't treat it differently from other
windows; and b) adds support in the Mac driver for doing OpenGL on the desktop
window.
This allows Worms Armageddon to work with the Mac driver without its
Wine-specific tweaks. It's sort of a proof of concept of the plan I mentioned
in my last reply.
NOTE: This will not work with the X11 driver because it doesn't have support
for doing OpenGL on the desktop window. (The X11 driver actually has code
specifically to reject attempts to do so, as did the Mac driver before this
hack.) The ddraw hacks will actually break the ability of the X11 driver to
run WA when its tweaks are active.
I also don't expect this to work with DirectDrawRenderer=gdi.
--
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.