wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Calendars
by William Lahti 24 May '04

24 May '04

I am trying to implement EnumCalendarInfo and would like to know if any locales have multiple calendars, where the settings for the extra calendars would be in the nls file, and if any calendars have their own seperate file.

3 3

additional download for winehq download page
by Ivan 24 May '04

24 May '04

This patch adds lots of download to the winehq download page. Sending only to wine-devel for now, as I'm not sure they are all needed, but they could all be useful in some situation or another. Comment welcome. Ivan. p.s. Maybe we should have a download page just for m$ components?

3 2

Re: additional download for winehq download page
by Ivan 24 May '04

24 May '04

> The link to the images is broken, it is winedows.gif when it should be > windows.gif. Yes, I've just noticed that. Ivan.

1 0

Re: Check that at least one drive is defined on startup
by Alexandre Julliard 24 May '04

24 May '04

Mike Hearn <mh(a)codeweavers.com> writes: > Mike Hearn <mh(a)codeweavers.com> > Add a check to process_init() to ensure at least one drive is defined, > as things break if that isn't the case. There is no need to define the Drives registry key, everything should work fine without it. If something doesn't, that's a bug. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Split the dsound test
by Robert Reif 24 May '04

24 May '04

Francois Gouget wrote: > > You will notice the following problems: > * the test takes awfully long (>6 minutes here). It loops through the > known formats and for each of them it plays, in turn, the regular > test, a test through a duplicated buffer, with a listener, etc. > * as a result of the above, a user listening to the test does not > know what to expect, which makes it hard to know whether the sound was > played correctly. The corresponding Microsoft test takes hours to complete. If time is an issue, then the test should be split up into a quick test and an exhaustive test. Also, volume and pan tests on primary and secondary buffers is not the same thing as 3D. They just happen to be similar now because we don't support hardware acceleration yet.

2 2

Re: Split the dsound test
by Robert Reif 24 May '04

24 May '04

Francois Gouget wrote: >+ >+#define NB_FORMATS 24 >+extern const unsigned int formats[NB_FORMATS][3]; >+ > > Please don't do this. It is desirable to be able to add or comment out formats easily when using this test as a debugging and development tool.

1 0

failure report: Astrum installer
by Dan Kegel 23 May '04

23 May '04

Looking through the debug log for my failed attempt to install picasa, I saw that the installer it uses is called Astrum; see http://www.thraexsoftware.com/aiw/ A free demo of that installer is downloadable from http://www.thraexsoftware.com/download/aiw.exe Predictably, it doesn't run under Wine, either; it also puts up a dialog box at the beginning (which unhelpfully doesn't show any text), and if you click "ok", it just puts up the same dialog box again. I tried for a while to figure out WINEDEBUG settings that would provide some illumination about what's wrong. Best I came up with was WINEDEBUG=warn+all,+dialog,+text wine aiw.exe > log 2>&1 in hopes I could tell what the missing text was, but no dice. Given that this is a free-ish installer, and more apps might start using it than just Picasa, maybe it's worth looking into... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: [ros-cvs] CVS Update: reactos
by Steven Edwards 23 May '04

23 May '04

Hello Dmitry, --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Yes, Wine is not perfect. No offence intended, but when ReactOS will > be able > to run at least MS Office XP then you could start comparing our > implementations > and state that Wine is not perfect in comparison. Right now I'm > afraid that > comparison is not on the ReactOS side, and just not using Wine source > is plain > wrong and just a big mistake. I agree with you and wish we could share more. I discussed abstracting WINE user32/gdi32 and creating a Win32k.sys implementation for Wine so we could try to hide the x11drv behind it but at the time Alexandre does not seem very interested in the idea. The way it stands right now while WINE is more correct in its functionality its implementation is not 100% correct for the design we are trying to replicate. If we can change this in WINE, then sure lets share even more and stop duplicating work. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

2 1

Re: Fix elf_read_wine_loader_dbg_info() declaration for the !__ELF__ case
by Eric Pouech 23 May '04

23 May '04

> -unsigned long elf_read_wine_loader_dbg_info(struct process* pcs) > +BOOL elf_read_wine_loader_dbg_info(struct process* pcs) > { > return -1; > } we should return FALSE too

1 0

tlhelp32 problem
by andrejoh＠c2i.net 23 May '04

23 May '04

Hi! While trying to get Anarchy Online working with Wine, I discovered that dynamically getting symbols from the running program does not work properly in Wine. The attached example code shows the problem; when running in Windows, I get this output The mangled name is "?Instantiate@MyTestClass@@SAPAV1@PAVObjectArchive_c@fun@@@Z" Searching in "ntdll.dll" Searching in "kernel32.dll" Searching in "Factory.dll" Searching in "MSVCP60D.dll" Searching in "MSVCRTD.dll" Searching in "Test.dll" Found the function at 00321023 Creating a new object! The returned text is "Found the right one!" whereas when running this in Wine, this is the output [andrej@rivendell tst]$ PATH=$PATH:$PWD wine tst The mangled name is "?Instantiate@MyTestClass@@SAPAV1@PAVObjectArchive_c@fun@@@Z" Searching in "" Searching in "" Searching in "" Searching in "" Searching in "" Searching in "" Searching in "" Searching in "" The returned text is "<function for "MyTestClass" not found>" If the test for a ".dll" ending is removed (as can be seen in the output, the name returned is empty, so it will always fail), this is the output [andrej@rivendell tst]$ PATH=$PATH:$PWD wine tst The mangled name is "?Instantiate@MyTestClass@@SAPAV1@PAVObjectArchive_c@fun@@@Z" Searching in "" Searching in "" Found the function at 0x408a9023 Creating a new object! The returned text is "Found the right one!" (If anybody needs the compiled code, and/or MSDS project files, please contact me directly.) -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

2 3

great improvements!
by Marius Andreiana 23 May '04

23 May '04

Hi I've been using wine for a long time (without any MS Windows dll). I've upgraded it to the latest version rpm once I installed Fedora Core 2 and I've happily noted these improvements: * /etc/wine for global config options * automatic creation of ~/.wine (drives, C:) There are still some fedora core issues, already in bugzilla. As the roadmap says, would be nice to have stable releases which focus on running by default (without any tweaks) common software, such as IE and Photoshop. (like crossweaver office) Thanks! -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro

1 0

Unhandled exception
by RT 23 May '04

23 May '04

I received the below message on FreeBSD 5.2.1-RELEASE, Wine 20040505 while playing Total Annihilation (non-demo). err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x0 #0 wine_get_thread_data () at pthread.c:534 534 return NtCurrentTeb()->pthread_data; (gdb) backtrace #0 wine_get_thread_data () at pthread.c:534 #1 0x00111e09 in __pthread_thread_self () at kthread.c:106 #2 0x00111e38 in __errno_location () at kthread.c:121 #3 0x00111e48 in __error () at kthread.c:124 #4 0x2020e406 in .cerror () from /lib/libc.so.5 #5 0x00111f19 in cleanup_thread () at kthread.c:198 -- Rod Taylor <rbt [at] rbt [dot] ca> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL PGP Key: http://www.rbt.ca/signature.asc

1 0

Re: Building wine on darwin (resend) (3/6)
by Alexandre Julliard 22 May '04

22 May '04

emmanuel maillard <e.rsz(a)libertysurf.fr> writes: > changelog > Add darwin/ppc support in THREAD_InitStack I'm not sure what the problem is, but the fix doesn't look right at all. Tib.StackBase should point to the base of the stack as it has been allocated, no matter how it's used later on. Most likely you need to fix wine_switch_to_stack or something like that. -- Alexandre Julliard julliard(a)winehq.org

4 4

Fwd: TGMarlett
by David Hammerton 22 May '04

22 May '04

Thanks Steven, However - just a thought here.. Do we want to simply work with the '.ttf' file, or should we keep the 'source' in CVS also? The 'source' file is a '.sfd' file created with PfaEdit [http://pfaedit.sourceforge.net/oldindex.html] now called FontForge [http://fontforge.sourceforge.net/]. I'm not really familiar with what extra data the '.sfd' file may have compared to the '.ttf' that may be useful. Is anyone familiar with this stuff? Is the '.sfd' pretty much useless when we have the '.ttf'? Either way, both can be found here (although the '.ttf' Steven sent is probably better, as it contains those fixes he mentions): http://craz.net/files/ Cheers, David Begin forwarded message: > From: Steven Edwards <steven_ed4153(a)yahoo.com> > Date: May 19, 2004 9:21:18 AM GMT+10:00 > To: wine-patches(a)winehq.com > Subject: TGMarlett > Reply-To: wine-devel(a)winehq.org > > Hello, > This is a update to the Marlett replacement developed by TransGamming. > It is needed to get Steam working on Wine. Sylvain Petreolle has hacked > it a bit so it will now load on Windows as well as ReactOS and Linux > with FreeType. The older TGMarlett did not work properly on WindowsXP. > > Thanks > Steven > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! - Internet access at a great low price. > http://promo.yahoo.com/sbc/ > -- David Hammerton david(a)craz.net http://crazney.net/ Welfare *NOT* Warfare

1 0

symbol hiding - with gcc -fvisibility
by Guido Draheim 21 May '04

21 May '04

sorry, just saw the note on WWN. I did hope that there would be someone to point to the gcc visibility stuff already - but it seems that people are more concerned to exchange their believes and politics rather showing off some engineering stuff. * preface: it's not in the file format - it's in the tools. The name ELF stands for Extensible Linker Format, it allows to invent all kind of new sections, and expand the symbol table with many interesting attributes that can be checked up by a toolchain. Well, "IF" the tools check for them. * gcc -fvisibility The gcc -fvisibility exists since 3.1 and is supported by binutils. If you read up some web reports, it seems to have been invented for hiding stuff not quite unlike what the original poster wanted. The icc supports all -fvisibility options as well afair. * the real problem traditionally, one can kill local systems which are usable within one file only, i.e. "static". Pretty 20year old unix stuff. The other symbols are referencable outside (in .o) and the standard shard linker will put all of them into the shared library symbol export table. - But now we want two different symbol flavours, one exported to the same library, the others for the rest of the world. Perhaps use a linker script to decide later about symbol visibility. * example solution gcc supports the universal attribute syntax, and it does now know about more symbol flavours as to their visibility. Probably you want to have "hidden". Attached are two simple test*.c files and a makefile. The final sharedlib symbol table contains only test3 after stripping. - using a linker script instead of in-source __attribute__ is left as an excercise to the reader. * more hints search freshmeat - there are ELF tools to staticlink, to obfuscate, and more. It's all in the tools. There is only one problem with opensource: many programmers do not need to hide symbols to the extreme, so they did not write such tools so far. Not yet. There are some real ELF-educated people out there - hire one, and let him write the tool you need. The ELF format is well-defined and simple enough to allow everything and quite easily. Do ut des. -- cheers, guido http://google.de/search?q=guidod extern void test2(void); void __attribute__((visibility("hidden"))) test1(void) { test2(); //__attribute__((visiblity("internal"))) } extern void test1(void); void __attribute__((visibility("hidden"))) test2(void) { test1(); } void test3(void) { test2(); } test.so : test1.c test2.c Makefile gcc -Wl,-x -shared -o $@ test1.c test2.c strip -x $@ objdump -t $@ | grep "test[123]" gcc -Wl,-x -shared -o test.so test1.c test2.c strip -x test.so objdump -t test.so | grep "test[123]" 00000631 g F .text 0000000d test3

3 3

WINE filesystem idea
by Jonathan Wilson 21 May '04

21 May '04

Basicly, when emulated windows version is set to NT4, 2000, XP or 2003, WINE should pretend to apps that its running on NTFS. If running as 95,98 or ME, it should pretend to apps that its running on FAT32. Or better yet, add an option for this (with my suggestions being the default) Just an idea :)

2 1

Wine on AMD64 (heap problem)
by Maurizio Monge 21 May '04

21 May '04

Hello, i compiled wine cvs on my amd64 without many problem (i had to set PATH to point to a directory with wrappers for gcc,ld and as that would call respectively "gcc -m32","ld -melf_i386","as --32", it would be nice if wine would support natively this or would support LDFLAGS=-melf_i368.., but this is not the point). When i started wine i got: wine: failed to create the process heap The same wine executable was running ok on my 32bits distro. I read that this happens on fedora2 too because of nx stack, and i think that, even if i do not have SeLinux installed, the stack is not executable by default on amd64... Do you have any idea of how this could be fixed/hacked? Thanx Maurizio I am not subscribed to wine-devel, so please CC monge(at)sns(dot)it

4 7

Regression with Blizzard patching software
by Aneurin Price 21 May '04

21 May '04

I recently discovered that the software used by Blizzard to patch Diablo 2 and Warcraft 3 (and possibly the same version used with other games), has stopped working. It starts do do something, but before actually applying the patch it crashes out, with the final error message being: Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x408ba2e0). In 32-bit mode. 0x408ba2e0 (DIALOG_CreateIndirect+0x300 [dialog.c:636] in USER32.DLL): movl $0x0,0x0(%eax) 139 return TRUE; Wine-dbg>WineDbg terminated on pid a The whole of the scrollback buffer is filled with the usual messages about loading debug information. I could run it with script to see what's happening before that, but I don't think it's really necessary: Since this *used* to work, I've gone through some CVS regression testing and determined that it stopped working sometime between 2004-04-19 22:00:00 and 2004-04-19 22:03:00 CST, so I'm willing to bet that this is what changed: http://www.winehq.org/hypermail/wine-cvs/2004/04/0272.html Since I have no understanding of what's going on here I really coudn't suggest a fix, but I'm happy to provide any further information I can and thought this would be worth pointing out. Aneurin Price

4 3

Re: loader fix for dbghelp
by Alexandre Julliard 20 May '04

20 May '04

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > I fixed that by sending (in ntdll loader code) the DLL load event a > bit later in the loading processus, when we're out of the dlopen call. This will break dlls that are loading implicitly by ELF loading. That stuff really has to be done in the constructor. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Empty (Stubs in spec only) d3drm
by Ivan Leo Murray-Smith 20 May '04

20 May '04

What app do you know about that uses this dll and works with the native version? All the DX7SDK samples fail with the native version. Ivan.

1 0

Fedora Core
by gslink 20 May '04

20 May '04

I notice that a problem has been detected with Fedora Core 2 but has anyone checked Core 3? That is the one in directory 1.92.

1 0

x - D3D Errors while starting
by Florian Goth 20 May '04

20 May '04

I tried to start The Game x and it bailed out with a lot of fixme's and some errors like these: err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0000001e) value : 00000000 ! The game uses DiectX6 There's a demo available at http://www.egosoft.com/x/download/index.htm This is the complete log: ixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40434ab0)->(00020022,00000013) fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now. fixme:ole:CoCreateInstance no instance created for interface {279afa83-4981-11ce-a521-0020af0be560} of class {d8f1eee0-f634-11cf-8700-00a0245d918b}, hres is 0x8000ffff fixme:dsound:IDirectSoundImpl_SetCooperativeLevel level=DSSCL_PRIORITY not fully supported err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (0000000a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (0000000b) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (0000000c) value : 0000000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (0000000d) value : ffffffff ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (00000010) value : 00000001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0000001e) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (00000028) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (00000030) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (0000008a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (00000097) value : 00000000 ! fixme:amstream:AM_create ((nil),0x4095f5ec) fixme:amstream:IAMMultiMediaStreamImpl_QueryInterface (0x404ddbf0/0x404ddbf0)->({bebe595c-9a6f-11d0-8fde-00c04fd9189d},0x439644d0) fixme:amstream:IAMMultiMediaStreamImpl_AddRef (0x404ddbf0/0x404ddbf0) fixme:amstream:IAMMultiMediaStreamImpl_Release (0x404ddbf0/0x404ddbf0) fixme:amstream:IAMMultiMediaStreamImpl_Initialize (0x404ddbf0/0x404ddbf0)->(0,1,(nil)) stub! fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream (0x404ddbf0/0x404ddbf0)->((nil),0x495398,0,(nil)) stub! fixme:amstream:IAMMultiMediaStreamImpl_GetFilterGraph (0x404ddbf0/0x404ddbf0)->(0x439645e0) stub! fixme:quartz:QUARTZ_DllGetClassObject {4a2286e0-7bef-11ce-9bd9-0000e202599c}: no class found. fixme:ole:CoCreateInstance no classfactory created for CLSID {4a2286e0-7bef-11ce-9bd9-0000e202599c}, hres is 0x80040111 fixme:amstream:IAMMultiMediaStreamImpl_OpenFile (0x404ddbf0/0x404ddbf0)->(0x4095f694,0) stub! fixme:amstream:IAMMultiMediaStreamImpl_GetMediaStream (0x404ddbf0/0x404ddbf0)->(0x495398,0x439644e4) stub! wine: Unhandled exception (thread 0009), starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 8 224") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger fixme:winmm:MMDRV_Exit Closing while ll-driver open

2 1

crosstest seems to be broken
by Kevin Koltzau 20 May '04

20 May '04

I noticed my crosstest build last night failed on module.cross.o(.text+0x713): In function `testGetModuleFileName': /home/wine/wine/dlls/kernel/tests/module.c:63: undefined reference to `wine_dbgstr_wn' module.cross.o(.text+0x727):/home/wine/wine/dlls/kernel/tests/module.c:63: undefined reference to `wine_dbgstr_an' looks like this patch introduced the problem http://cvs.winehq.org/patch.py?id=12409 I won't have time to work on this in the next few days..so if someone could take a look at this I'd be most appreciative

1 0

Bug in EndDialog
by Santosh Siddheshwar 19 May '04

19 May '04

Hi, I think there may be a bug in EndDialog. Attached is a simple app which work fines on Windows but hangs on Linux. Follow the steps below to reproduce the problem. 1. Create the Sample2.exe from the attached project. 2. Run Sample2.exe 3. Click on Help | About menu item 4. Click on the OK button 5. App Hangs. Any clues? Regards Santosh Siddheshwar <<Sample2.zip>> ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

some ideas for new janitorial projects
by Eric Pouech 19 May '04

19 May '04

I've been toying with some gcc warnings lately, and this could generate some new ideas for janitorial tasks. For example: o -Wmissing-declarations should point lots of missing APIs declarations (I've done it in some cases, and I'm in the process of submitting some fixes). We cannot turn this warning always on because there are lots of cases where we have global functions without prototypes (most than 2/3 of them are made out of the 16bit entry points) o -Wcast-qual should point out all the (const bla*) => (foo*) casts. We use quite a bit this, and in some cases it would prevent some errors. These are the main cases pointed out by this warning: 1/ const void* ptr; and then reading a value from ptr (word...) like *(WORD*)ptr which should be written *(const WORD*). The warning in this case is harmless. 2/ const void* ptr; and then setting it to another const pointer: const WORD* pw = (WORD*)ptr; which should be written pw = (const WORD*)ptr;. This warning is harmless if pw is really defined as const, in some cases it isn't and this should be fixed. 3/ const void* ptr; and then setting it to a pointer to a pointer (used a lot for qsort/bsearch... callbacks), when dealing with arrays of pointers. Here again, what's const is the first pointer, so const foo* f = *(const foo**)ptr is wrong, it should be const foo* f = (const foo* const*)ptr; This could be harmfull if not declared properly. Unfortunately, we cannot turn this warning on all the time because some C functions implementation would always trigger it (strstr for example), unless we use intergral values (not pointer) to cast from the const char* to the returned char*), and this is uglier IMO than the warning we try to avoid. Some others warnings could be used as well. Trying also the Intel compiler gave lots of interesting warnings (and a tons of not so usefull too). A+

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel