Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it works fine, and I
believe what we have is more or less ready for CVS. However Vitaly told me Alexandre didn't like the
object manager Vitaly wrote, mostly he didn't like permanent objects, that drivers depend on. I
haven't talked to Alexandre about this but hopefully some reasonable solution can be found so we can
get Vitaly's OM into wineserver (I mean my original implementation that uses pointers as handles
…
[View More]also works, but things look better with a real OM). So let's try and trigger some community
discussion, we are talking about the guts of wine after all. Vitaly, what's the OM status currently?
Alexandre, what didn't you like about it?
Ivan.
[View Less]
Hi,
I've been playing with getting CIV4 to run on wine.
http://appdb.winehq.org/appview.php?versionId=3632&iTestingId=125
I'm left with just one issue.
D3DX9_26.DLL is missing. This is a D3D9 SDK release (they put one out every
month or so from what I've seen, with a new DLL that has the number
incremented). It's mostly like the original with some minor changes.
How would I support this in wine? I don't know the wine build system enough
to extend it to do this.
Is there a nice way to …
[View More]generate these DLLs and to include the d3dx9 dll so I
just have to add in/fix missing calls?
This may not be an issue now, but as more and more games get released more
will depend on these dlls.
Thanks,
Andrei
[View Less]
Just for the info: after some digging i found a quick
hack to get rid of the error: comment line 208 in
dlls/x11drv/opengl.c:
//TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO,
GLX_STEREO);
Somehow setting the PFD_STEREO flag makes doom3 crash
and triggers the error mentioned in the subject.
After commenting line 208 doom3 starts up just fine.
Digging further..... :)
(any help appreciated) Louis
___________________________________________________________
To help you stay safe and …
[View More]secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
[View Less]
On 11/17/05, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
> I didn't see point in adding HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)
> value into every checks for TranslateInfString(), as all they fails in the
> same way later. I guess, this is because of NT3.51 unability to parse
> usual INF-files.
>
> Log message:
> Saulius Krasuckas <saulius.krasuckas(a)ieee.org>
> Exit test after first TranslateInfString() failure, which seems to
> …
[View More] be NT3.51 specific.
>
I don't think this is correct. I don't have hands on access to this
NT3.51 machine, so it's hard to tell, but it sounds like there's a
problem creating the file c:\test.inf for whatever reason. I'll send
a patch to wine-patches that adds an ok to check that the file was
created successfully.
--
James Hawkins
[View Less]
I've been doing some tests with the odd Dreamweaver problem that I
originally thought was a regression and discovered the following:
1) If I compile the current CVS on my Mandriva 2005LE machine with gcc
v.3.4.3, then install it to my Mandriva 2006 desktop, Dreamweaver works
fine.
2) If I compile the current CVS on my Mandriva 2006 desktop with gcc
v.4.0.1, then install it to that same machine, Dreamweaver hangs at the
splash screen (with the app window in background). Other apps, like
…
[View More]Steam and Counter-Strike: Source work fine under this install.
This is using the same .wine config directory and everything. I used
"make clean" and "wineserver -k" between compiles.
When I was originally troubleshooting it as a Dreamweaver problem, I
recall checking out a fresh copy of CVS and getting the same hangup
symptoms under 4.0.1.
So, it appears that this might be caused by either a gcc 4.0.1 bug, or a
bug in the WINE source that only becomes evident when compiled under gcc
4.0.1.
When I get home from work tonight I can do some traces to try to narrow
the scope of investigation. Are there any trace options that would be
particularly helpful to you devs?
Thanks,
Jesse
[View Less]
As the subject says, all of the WGL functions that should be declared in
wingdi.h are currently only found in dlls/opengl32/wgl.h. I ran across this
recently while working on getting wined3d to use wgl instead of glx directly.
Currently I work around it by including wgl.h and adding makefile include
options to point to dlls/opengl32. It would be much cleaner and correct if I
could forgo this and just include wingdi.h. Anyone have problems with me
submitting a patch which would move the …
[View More]relevant (i.e. not all) parts of
dlls/opengl32/wgl.h into include/wingdi.h?
>From MSDN (for wglCreateContext):
===
Requirements
Windows NT/2000: Requires Windows NT 3.5 or later.
Windows 95/98: Requires Windows 95 or later. Available as a redistributable
for Windows 95.
Header: Declared in wingdi.h.
Import Library: Use opengl32.lib.
===
Regards,
Aric
[View Less]
Hello again!
Running Origin6.0 with WINEDEBUG="+snoop,+relay" with and without native msvcrt, tailing, cutting and wc-ing and finally diffing the output I found the following:
First of all using the native version I get some msvcrt._EH_prolog calls I can't find in the builtin version.
all window-procs have such calls:
native:
ret kernel32.94() retval=00000009 ret=7f6c5a5c
call window proc 0x6c231b81 (hwnd=0x1003a,msg=wm_settext,wp=00000000,lp=7fadedd4)
call msvcrt._eh_prolog(7f6cf147,…
[View More]0001003a,0000000c,00000000,7fadedd4 "microcal origin - i
ret msvcrt._eh_prolog() retval=7db10190 ret=6c231b8b
call msvcrt._eh_prolog(6c231b9c,6c23b419,6c231b81,6c231b81,7fadf8ec,6c2c2cfe,ffffffff0009
ret ntdll.rtlentercriticalsection() retval=00000000 ret=7e6563d2
call ntdll.rtlleavecriticalsection(7e69a888) ret=7e656412
ret ntdll.rtlleavecriticalsection() retval=00000000 ret=7e656412
\\mnt\\privat\\origin6\\untitled",7f6ee620,0001003a,0000000c, ...) ret=6c2310b5
ret msvcrt._eh_prolog() retval=7db10190 ret=6c2310b5
call kernel32.tlsgetvalue(00000003) ret=6c231018
ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018
call msvcrt._eh_prolog(6c23138a,00000000,6c231be9,0001003a,7fadeba8,6c231bba,0001003a,0000000c,00000000,7fadedd4 "microcal origin - i
ret msvcrt._eh_prolog() retval=7db10190 ret=6c23112a
call kernel32.tlsgetvalue(00000003) ret=6c231018
ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018
call kernel32.tlsgetvalue(00000003) ret=6c231018
ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018
call msvcrt._eh_prolog(6c231bfb,7d9366c0,0001003a,0000000c,00000000,7fadedd4 "microcal origin - i
ret msvcrt._eh_prolog() retval=7db10190 ret=6c231c09
call kernel32.tlsgetvalue(00000003) ret=6c231018
builtin:
call window proc 0x6c231b81 (hwnd=0x1003a,msg=wm_settext,wp=00000000,lp=7fadedd4)
call kernel32.tlsgetvalue(00000003) ret=6c231018
This is another example not concerting window procs:
native:
call kernel32.lstrlena(7fadecc0 "microcal origin") ret=6c2338d7
ret kernel32.lstrlena() retval=0000000f ret=6c2338d7
call msvcrt._eh_prolog(6c2319c6,0000000f,7fadedd0,7fd299fc,6c23393c,0000000f,0000000f,7fadedd0,6c2338f9,0000000f,7fadecc0 "microcal origin",7fadedd0,6c2338e0,0000000f,7fadecc0 "microcal origin",0000000f, ...) ret=6c231aeb
ret msvcrt._eh_prolog() retval=7db101a9 ret=6c231aeb
call ntdll.rtlentercriticalsection(6c300088) ret=6c231b03
same as builtin:
call kernel32.lstrlena(7fadecc0 "microcal origin") ret=6c2338d7
ret kernel32.lstrlena() retval=0000000f ret=6c2338d7
call ntdll.rtlentercriticalsection(6c300088) ret=6c231b03
>From mfc there is also such a call:
native:
call mfc42.6374(0000000c,00000000,7fadedd4 "microcal origin - i
call mfc42.5163(0000000c,00000000,7fadedd4 "microcal origin - i
call msvcrt._eh_prolog(7db101db,0000000c,00000000,7fadedd4 "microcal origin - i
ret msvcrt._eh_prolog() retval=7db101f4 ret=6c231d16
call ntdll.rtlentercriticalsection(6c300220) ret=6c23178e
builtin:
call mfc42.6374(0000000c,00000000,7fadedd4 "microcal origin - i
call mfc42.5163(0000000c,00000000,7fadedd4 "microcal origin - i
call ntdll.rtlentercriticalsection(6c300220) ret=6c23178e
Then there is also a difference when calling ftime():
native: (line 16240)
call msvcrt.memcpy(7d945558 "untitled",7fe5e27a "untitled",00000008) ret=6c233905
ret msvcrt.memcpy() retval=7d945558 ret=6c233905
ret mfc42.860() retval=7d943dc0 ret=7f81a080
call outl60.labutil_str2date(00000000,00000003,00000000) ret=7f81a0fe
call msvcrt._ftime() ret=7f74100d
call kernel32.getsystemtimeasfiletime(7fadedf0) ret=78026aad
call ntdll.ntquerysystemtime(7fadec80) ret=7fd08e30
ret kernel32.getsystemtimeasfiletime() retval=01c5f531 ret=78026aad
ret msvcrt._ftime() retval=438cd1d8 ret=7f74100d
call msvcrt.localtime() ret=7f74103e
call kernel32.getlasterror() ret=78002699
ret kernel32.getlasterror() retval=00000000 ret=78002699
call kernel32.tlsgetvalue(00000002) ret=780026a7
ret kernel32.tlsgetvalue() retval=7d930088 ret=780026a7
call kernel32.setlasterror(00000000) ret=780026b8
ret kernel32.setlasterror() retval=00000000 ret=780026b8
ret msvcrt.localtime() retval=7d9306f8 ret=7f74103e
builtin: (line 16632)
call msvcrt.memcpy(7fe7dff8,7fe637e2,00000008) ret=6c233905
ret msvcrt.memcpy() retval=7fe7dff8 ret=6c233905
ret mfc42.860() retval=7fe7aac0 ret=7f81a080
call outl60.labutil_str2date(00000000,00000003,00000000) ret=7f81a0fe
call msvcrt._ftime(7f75b778) ret=7f74100d
call kernel32.gettimezoneinformation(7fadec9c) ret=7e886be4
call ntdll.rtlquerytimezoneinformation(7fadec9c) ret=7fd09bce
ret ntdll.rtlquerytimezoneinformation() retval=00000000 ret=7fd09bce
call ntdll.ntquerysystemtime(7fadebc0) ret=7fd08e30
ret kernel32.gettimezoneinformation() retval=00000000 ret=7e886be4
call kernel32.getsystemtimeasfiletime(7faded48) ret=7e886bf3
call ntdll.ntquerysystemtime(7fadebe0) ret=7fd08e30
ret ntdll.ntquerysystemtime() retval=00000000 ret=7fd08e30
ret kernel32.getsystemtimeasfiletime() retval=01c5f530 ret=7e886bf3
ret msvcrt._ftime() retval=00000000 ret=7f74100d
call msvcrt.localtime(7f75b748) ret=7f74103e
call kernel32.filetimetolocalfiletime(7faded48,7faded40) ret=7e886e9a
call ntdll.rtlsystemtimetolocaltime(7fadeba4,7fadebac) ret=7fd09f03
ret ntdll.rtlsystemtimetolocaltime() retval=00000000 ret=7fd09f03
ret kernel32.filetimetolocalfiletime() retval=00000001 ret=7e886e9a
call kernel32.filetimetosystemtime(7faded40,7faded30) ret=7e886ea4
call ntdll.rtltimetotimefields(7fadebb0,7fadeba0) ret=7fd09572
ret ntdll.rtltimetotimefields() retval=0000016f ret=7fd09572
ret kernel32.filetimetosystemtime() retval=00000001 ret=7e886ea4
call kernel32.gettimezoneinformation(7fadec84) ret=7e886fd1
call ntdll.rtlquerytimezoneinformation(7fadec84) ret=7fd09bce
ret ntdll.rtlquerytimezoneinformation() retval=00000000 ret=7fd09bce
call ntdll.ntquerysystemtime(7fadeb98) ret=7fd08e30
ret ntdll.ntquerysystemtime() retval=00000000 ret=7fd08e30
ret kernel32.gettimezoneinformation() retval=00000000 ret=7e886fd1
ret msvcrt.localtime() retval=7e8ae660 ret=7f74103e
And the native msvcrt seems to use an internal _ftol
native:
call msvcrt._cipow() ret=7f82aaf9
ret msvcrt._cipow() retval=40f00020 ret=7f82aaf9
call msvcrt._ftol() ret=7f82a67a
ret msvcrt._ftol() retval=00000001 ret=7f82a67a
builtin:
call msvcrt._cipow() ret=7f82aaf9
ret msvcrt._cipow() retval=00000001 ret=7f82aaf9
call ntdll._ftol() ret=7f82a67a
ret ntdll._ftol() retval=0000000000000001 ret=7f82a67a
By the way... what is the difference between "retval" and "ret"? It sounds the same.
There are still some megs in front of me... Perhaps you could comment my discoveries so far. Personally I think they aren't very important, but I really don't know much about the win32 api, so I can't tell...
Ciao,
Olaf Leidinger
[View Less]
The networking bug has been fixed, but another problem is that I can't
see any of the text. Appdb mentions something about installing
tahoma.ttf from a Windows installation, which makes no sense to me,
since I could see Steam displayed fine earlier, making this a
regression. Any suggestions as to what might have caused this (or maybe
it was a Steam upgrade?).
Also - Steam has a keyboard focus bug, with a documented patch here
(from Stefan Dosinger):
http://www.winehq.org/hypermail/wine-…
[View More]patches/2005/03/0504.html
Previously he reported that the patch might break other apps, but if it
fixes Steam, then it must be on the right track - surely it can be
changed so it's acceptable for Wine CVS. I don't understand why a known
bug with a known patch remains unfixed.
[View Less]
Hello!
Today I have finally managed to get some useable graphics with D3D7 and
WineD3D. The Tomb Raider 3 Demo is running. :)
The only visible problem I can see are textures: They only have a solid color,
all other things seem to work. I've uploaded a screenshot to
http://doesi.gmxhome.de/tomb3-2.png , if anyone wants to have a look.
I'll try to fix the textures and get some more games running, then I'll upload
a beta patch somewhere for others to try. (Well, if anyone is interested, I
…
[View More]can mail the current code too).
Greetings,
Stefan
[View Less]
The way I would recommend for pci bus scanning is to parse
/proc/bus/pci/devices the only problem is that this is linux specific.
Something similar can be done on other OSes though. Another way which is
more portable is to use libpci but it isn't installed on all systems. Guess
something like this would need to be added to some 'kernel' dll...
Roderick
>
> PS: if one of you know a way to implement pci bus scanning on wine i'll be
> happy
>
--
10 GB Mailbox, 100 FreeSMS/Monat …
[View More]http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f�r Mail, Message, More +++
[View Less]