http://bugs.winehq.org/show_bug.cgi?id=4628
------- Additional Comments From ahziem1(a)mailbolt.com 2006-23-02 08:53 -------
Here mp71.exe installation quits with the error message "The Windows Media
Update Notifier is currently unable to detect available updates. Please try
again later." But there is no freeze.
System
- Fedora Core 4
- WINE CVS 2006-02-20 compiled with GCC 4.0.2
- WINE 0.9.7 from RPM
--
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=4643
------- Additional Comments From ahziem1(a)mailbolt.com 2006-23-02 08:45 -------
>What format is your c: drive? is is dos format by any chance?
According to winecfg, it is autodetect, so I changed it to local hard drive, and
the error persists.
In older versions of WINE, I remember there being a DOS option, but I don't see
it anymore.
> how is it mounted and what is the contents of you /etc/fstab file?
c: points to ~/.wine/drive_c (default)
$ cat /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
/dev/VolGroup00/home /home reiserfs defaults 1 1
/dev/devpts /dev/pts devpts gid=5,mode=620 0 0
/dev/shm /dev/shm tmpfs defaults 0 0
/dev/proc /proc proc defaults 0 0
/dev/sys /sys sysfs defaults 0 0
LABEL=SWAP-hda8 swap swap defaults 0 0
/dev/hda5 /mnt/win_e auto
defaults,gid=500,umask=0000 0 0
/dev/hda2 /mnt/win_d auto
defaults,gid=500,umask=0000 0 0
/dev/fd0 /media/floppy auto
pamconsole,exec,noauto,managed 0 0
/dev/hdd /media/cdrecorder auto
pamconsole,exec,noauto,managed 0 0
/dev/hdc /media/cdrom auto
pamconsole,exec,noauto,managed 0 0
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda7 5.4G 4.3G 929M 83% /
/dev/mapper/VolGroup00-home
112G 68G 45G 61% /home
/dev/shm 363M 0 363M 0% /dev/shm
/dev/hda5 4.9G 4.7G 194M 97% /mnt/win_e
--
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=4643
------- Additional Comments From tony.lambregts(a)gmail.com 2006-23-02 08:36 -------
What format is your c: drive? is is dos format by any chance? how is it mounted
and what is the contents of you /etc/fstab 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=4490
tony.lambregts(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://www.aim.com/get_aim/w
| |in/other_win.adp?aolp=
Keywords| |download
------- Additional Comments From tony.lambregts(a)gmail.com 2006-23-02 08:32 -------
Actually, Jacek Caban in comment #6 was asking if reverting the patch on a
current version would fix the issue first and if it did not to submit a trace.
I take it you are useing a packaged version of wine and not compiling from source.
If you compile from source you can reverse teh patch by downloading the patch to
the root wine directory and issuing the patch command in wine root directory
patch -p0 -R < name of patch.
After that you can recompile wine.
./configure
make depend && make
su make install
--
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=2398
------- Additional Comments From d.oosterveld(a)wanadoo.nl 2006-23-02 07:18 -------
I'm using these applications on a laptop with not much such 3d muscle as a
desktop card. I really need these applications to work. I've been poking the
0.9.2 sources to get Luxology Modo to work somewhat properly.
I managed to get the interface and opengl to draw at the same time by simply
disabling the double buffering. This ends up to be pretty cheap solution. The
only problem is positioning the opengl viewports because I don't have the
insight in the x11drv yet to implement:
- Reposition the viewport on every call to glViewport().
- Call glScissor to clip the viewport so it won't overdraw the interface.
- Adapt glClear to stay inside the scissored area.
And you should be done, giving a cheap and easy fix of the problem on
cards/drivers without a funky gl extension ;)
The second (and sane) solution is to use separate X child windows for each
openGL viewport. This can be done when the device context is attached, then you
can make an special exception for child windows with openGL attached. Most
programs use separate X (child) windows to position the openGL viewport because
it's so easy to do. The contents of these openGL subwindows is never draw by
GDI. X applications use the the same solution. But you probably now this ;)
Trying to blit a openGL viewport inside a window means reimplementing part of
the X window system and all driver specific trouble with it making the
implementation unreliable. The first implementation of the WM was very sweet for
this situation and lets X windows handle the complexity of clipping the viewport
and double buffering it.
I'd really like to have the first solution implemented as a switch as a
temporary solution even if it isn't double buffered. This would at least give us
somewhat usable applications.
Thanks.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=4490
------- Additional Comments From Speeddymon(a)gmail.com 2006-23-02 06:56 -------
what he is asking is run wine like this:
WINEDEBUG=+wininet,+seh,+tid wine aim.exe >crash.log
Then once it crashes, come back here and click the create a new attachment link
and upload crash.log
--
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=4075
------- Additional Comments From tyglik(a)hotmail.com 2006-23-02 06:16 -------
Hi.
I got simmilar error - on current(yesterdays) Fedora Core 4 Athlon rpm version
of wine.
I don't have an exact error message here but it was about files whose can not
be coppied.
I was thinking about it - and i think there is trouble about permissions for
directories when installing from CD ...
All directories which appeared in "C:" installation path kept their permitions
as they are on CD - CD is read only ..
Hopefully helps.
Martina
--
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=4634
------- Additional Comments From saulius.krasuckas(a)elst.vtu.lt 2006-23-02 05:12 -------
| And apparently the toolhelp.dll.ClassFirst is not yet implemented on WINE:
Though I think it should be implemented already:
$ ll dlls/toolhelp*
| -rw-rw-r-- 1 s2 s2 13 Feb 22 12:50 dlls/toolhelp.dll16
| lrwxrwxrwx 1 s2 s2 15 Feb 13 00:42 dlls/toolhelp.dll.so -> kernel32.dll.so
$ cat dlls/toolhelp.dll16
| kernel32.dll
Looks like another reference to the same builtin module "kernel32.dll".
$ cat dlls/kernel32.dll.so | strings | grep ClassFirst
| ClassFirst
| __wine_stub_ClassFirst
Stub?
$ grep -r ClassFirst dlls/kernel
| dlls/kernel/toolhelp.h:BOOL16 WINAPI ClassFirst16( CLASSENTRY *pClassEntry );
| dlls/kernel/toolhelp.spec:#69 pascal -ret16 ClassFirst(ptr) ClassFirst16
| dlls/kernel/toolhelp.spec:69 stub ClassFirst
| Binary file dlls/kernel/kernel32.dll.so matches
| Binary file dlls/kernel/toolhelp.spec.o matches
Stub, but lets go further:
$ grep -r ClassFirst dlls/*/*.c
| dlls/user/class.c: * ClassFirst (TOOLHELP.69)
| dlls/user/class.c:BOOL16 WINAPI ClassFirst16( CLASSENTRY *pClassEntry )
So, it's implemented, only in another module, in "user32.dll". I don't know
whether it can be forwarded at imports level. Probably it cannot. Kernel32
must not depend on User32, I guess.
Then it perhaps can be imported during run-time linking via GetProcAddres().
Or maybe the situation will change in nearest future as I saw AJ doing some
module-load-rewrite recently. :)
--
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=4497
------- Additional Comments From vitaliy(a)kievinfo.com 2006-22-02 22:20 -------
You have to attach not paste. After you do this 10 more times the bug report
will be in the perfect state for night reading.
--
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.