http://bugs.winehq.com/show_bug.cgi?id=1218
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:22 -------
Bug comments restored from Gmane.org:
During install of Adaytum Analyst on Debian Unstable (Wine 20021219) all goes
well with the setup and it installs Adobe Acrobat fine and launches into the
setup for Analyst. However, midway through the install it throws a
InstallShield error:
995: Internal error in Windows Installer
followed by InstallShield error:
1611: Unable to extract the file (null).
Wine itself never crashes.
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1217
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:20 -------
Bug comments restored from Gmane.org:
When I try to print something the job goes to spool but gets aborted. When I
print to file, the generated file is corrupted.
I tested it with several versions of wine from CVS and redhat 7.3 and 8.0 with cups.
All systems I tested prints ok from linux.
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1216
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:18 -------
Bug comments restored from Gmane.org:
when trying to run WinBUGS
http://www.mrc-bsu.cam.ac.uk/bugs/winbugs/contents.shtml
using wine, i cannot get the buttons to work properly. Pressing 'Doodle' and
then 'New', and then 'Ok' nothing happens. this means i cannot run the program.
i got some infomation about this behaviour from one reliable source, for which i
quote:
The latest version of wine that works with WinBUGS is wine-20010731.
Everything after that fails because buttons do not respond to being
clicked.
I have no idea what the problem is. I am disappointed that the bug
hasn't been fixed. It must be a very rare bug, only revealed by the
Black Box component framework (which supplies the controls used by
WinBUGS).
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1215
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:15 -------
Bug comments restored from Gmane.org:
(Version in use is actually 20021031, but this error has existed for a long
time, on both -current and -stable, from ports or CVS).
After using any windows binary I've tried with FreeBSD's wine from ports, I
eventually get an error:
wine in malloc(): error: recursive call
It also shows up as "wine in free(): error: recursive call," and sometimes
several of them can show up in the output. The application hangs soon
afterwards (I am guessing it's right when the malloc recursion happens). In
particular I've been trying to use the Exile 3 binary, but with that it happens
after some minutes of play. When I was trying counterstrike it happened very
quickly.
Notable excerpt from the malloc manpage:
recursive call A process has attempted to call an allocation function
recursively. This is not permitted. In particular, signal handlers
should not attempt to allocate memory.
However, I think I've tracked down the mallocs/frees that can happen as a result
of signals. One set (server/registry.c) I patched to not malloc/free. I put in
a printf around the segv handler, and this recursive malloc doesn't appear to be
happening during segv. Would the rforking(RFPROC|RFMEM) cause this?
------- Additional Comments From eta <at> lclark.edu 2003-02-20 18:13 -------
*** This bug has been confirmed by popular vote. ***
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1213
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:11 -------
Bug comments restored from Gmane.org:
I use wine in Russian language environment, and I can see, that it uses
windows-1251 as a default Russian encoding. Of course, it is correct, since
Windows applications usually should work with the windows codepage. Even in
Linux windows-1251 becames more and more popular, since it is really better,
than traditionally used koi8.
But the Cyrillic X11 keysyms, which I input from my keyboard, are recognized by
wine as koi8, and it is strange, since, I think, the keyboard encoding should
match the encoding used for screen. So I recommend to change 20866 to 1251 at
least for one Russian keyboard described in the file keyboard.c (there are 3
Russian keyboards in this file).
------- Additional Comments From andi <at> rhlx01.fht-esslingen.de 2003-01-14
09:43 -------
Just submitted a patch to change the main Russian keyboard's codepage to 1251.
------- Additional Comments From dpaun <at> rogers.com 2003-04-01 00:15 -------
Why was this bug marked FIXED? Reopening.
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1211
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:07 -------
Bug comments restored from Gmane.org:
Error Message Pops Up saying:
Warcraft III was unable to initialize DirectX. Please ensure you have DirectX
8.1 or newer installed and that your display drivers are current. DirectX may be
found on your Warcraft III install CD under Options.
Running Wine 20021219 with a WinXP partition
------- Additional Comments From us <at> the-edmeades.demon.co.uk 2003-01-09
17:27 -------
Keep updating wine as dx8 support is improving in wine over time. Make sure you
have wine compiled with --enable-opengl if required, and ensure your display is
not in a 24 bit display mode (There's an issue there as Warcraft doesnt like 24
bit displays - it must be 16 or 32 bit). If you still get the message, send me
a --debugmsg +d3d trace zipped up and I'll take a look.
(Note: I dont get _that_ error, it just doesnt work...)
Jason
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1210
------- Additional Comments From winebug(a)flonet.net 2003-23-06 13:05 -------
Bug comments restored from Gmane.org:
Hi,
I try to install wine-20021219 but I got this :
[...]
Preparing to install default Wine registry entries...
Installing default Wine registry entries...
FIXME:pthread_cond_init
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
Could not stat /cdrom (No such file or directory), ignoring drive D:
./tools/wineinstall: line 634: 22743 Segmentation fault $REGEDIT $DEFREG
>/dev/null
Registry install failed.
It would be great if you could help me with this !
Best regards,
Pierre.
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1238
------- Additional Comments From winebug(a)flonet.net 2003-23-06 12:57 -------
Bug comments restored from Gmane.org:
I'm using wine cvs sources as of 20030115 and am running on a
linux-2.4/glibc-2.3 based system.
When I tried to configure wine recently, I was interested in having IPX
support. However, configure was returning a negative result when it checked for
the necessary headers. After confirming that both netipx/ipx.h and linux/ipx.h
were present, I examined the autoconf macro more closely. It was then I
discovered that it was omitting a necessary header for IPX support on linux
systems: sys/socket.h. This is because the header is guarded by a test against
the existance of sys/socket.h.
The problem with the current wine configure.ac is that
AC_CHECK_HEADERS([sys/socket.h]) is placed *after* the check for IPX support.
This is most unfortunate and will result in false negatives previously
described.
The solution is to place AC_CHECK_HEADERS([sys/socket.h]) right after
AC_CHECK_LIB(mmap,mmap). This ensures that it will be properly defined in the
later test macros.
------- Additional Comments From marcus <at> jet.franken.de 2003-01-27 01:14
-------
fixed in CVS.
------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-02-19
22:13 -------
Closing
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1239
------- Additional Comments From winebug(a)flonet.net 2003-23-06 12:52 -------
Bug comments restored from Gmane.org:
I am a newbie. I have run into a problem in changing the gamma ramp due to the
size of my gamma ramp on my video card. There is a check in
xvidmode.c which disables the get/setgammaramp functions if the size of the
gamma ramp reported by the hardware is not 256. My gamma ramp size is
1024. I have made it work by modifying (defeating) the check and interpolating
the 256 size gamma ramp from the Windows program to the larger size
1024 gamma ramp in get/setgammaramp functions. Should learn how to submit my
ham fisted modification?
------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-01-24
22:42 -------
Yes. Ham fisted or not.
The following link gives general information on submitting Patches.
http://www.winehq.org/docs/wine-devel/patches.shtml
This will allow others to see your HACK^H^H^H^H patch and hopefully someone will
be able to give some constructive critisism so you can put together a patch that
can be acceptable.
--
Configure bugmail: http://bugs.winehq.com/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.com/show_bug.cgi?id=1240
------- Additional Comments From winebug(a)flonet.net 2003-23-06 12:48 -------
Bug comments restored from Gmane.org:
As shown in the URL image, what should be an invisible child window has the
WS_CAPTION style set.
trace:win:CreateWindowExW classname=#8002 stylehex=40c00440
trace:win:WIN_CreateWindowEx L"" L"#32770" ex=00000000 style=40c00440 -3,-22
456x253 parent=0x10021 menu=(nil) inst=0x400000 params=(nil)
trace:win:WIN_CreateWindowEx Styles before adjustment:
trace:win:dump_window_styles style: WS_CHILD WS_CAPTION 00000440
trace:win:dump_window_styles exstyle:
trace:win:WIN_CreateWindowEx winproc type is 3 (WIN_PROC_32W)
trace:class:CLASS_FindClassByAtom 0x00008002 0x400000
trace:class:CLASS_FindClassByAtom -- found global 0x40388118
0807a218:Call ntdll.RtlAllocateHeap(40360000,00000000,000000a2) ret=408be1fd
0807a218:Ret ntdll.RtlAllocateHeap() retval=403a0458 ret=408be1fd
trace:win:WIN_CreateWindowEx Styles after adjustment:
trace:win:dump_window_styles style: WS_CHILD WS_CAPTION 00000440
trace:win:dump_window_styles exstyle: WS_EX_WINDOWEDGE
trace:win:WIN_SetWindowLong 0x1002f -12 0 3
0807a218:Call x11drv.CreateWindow(0001002f,406b2884,00000001) ret=408bfffc
The app I'm testing with is at http://rhymbox.com/download/start.pl
The installer itself appears to set the WS_CAPTION flag when calling
CreateWindowEx. In Windows, spy++ shows that this flag isn't set, but the usage
of vc++ lazy bindings mean I can't get an API trace under windows :(
------- Additional Comments From andi <at> rhlx01.fht-esslingen.de 2003-01-26
18:36 -------
The only place in Wine to fix up WS_CAPTION is:
/* Correct the window style - stage 2 */
if (!(cs->style & WS_CHILD))
{
wndPtr->dwStyle |= WS_CLIPSIBLINGS;
if (!(cs->style & WS_POPUP))
{
wndPtr->dwStyle |= WS_CAPTION;
wndPtr->flags |= WIN_NEED_SIZE;
}
}
in windows/win.c/WIN_CreateWindowEx()
Checking windows/win.c cvs log, I'm thinking about:
----------------------------
revision 1.214
date: 2003/01/08 19:53:47; author: julliard; state: Exp; lines: +2 -2
Duane Clark <dclark <at> akamail.com>
WS_CAPTION is a two bit field, so test appropriately.
----------------------------
Hmm, could it be that this recent change caused you to notice the WS_CAPTION
problem ?
The WS_CAPTION fixup has been in windows/win.c since its CVS beginnings, BTW.
I think we can safely confirm this bug.
So the question is: what exactly should be corrected in that function and how ?
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.