wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Anyone have Wine PowerPoint slides?
by Ira Krakow 16 Feb '05

16 Feb '05

I'm giving a presentation on converting Windows programs to Linux at MIT (the Boston Linux User Group) on April 20th from 7pm to 9pm. The BLU may be the oldest Linux user group in the US. It's been around at least since 1993, has been meeting regularly since then, and has a lot of activity. The group started under the umbrella of the Boston Computer Society, which at one time had over 20,000 members. I was wondering if anyone has any Wine PowerPoint slides? I will do the presentation in PowerPoint under Crossover Office 4.1. I can either develop the slides myself or adapt and use slides that have been developed already. Maybe something from a previous WineConf? Thanks in advance. Ira

4 3

Re: portability fixes (yet another attempt)
by Mike McCormack 16 Feb '05

16 Feb '05

Thomas Weidenmueller wrote: > I'm however not sure about the changes in include/wine/port.h and > include/config.h so please adjust or correct them so it builds correctly. If you don't build and test your patches against Wine, then don't submit patches. If you're trying to fix Reactos, then why don't you just fix your own headers? Dmitry already pointed out that you can easily add some #define's or inline functions to achieve what you want. That seems like a better idea than submitting untested patches to wine-patches and hoping we're going to fix your problems for you. Mike

3 3

Re: winecfg: various drive detection enhancements
by Michael Jung 16 Feb '05

16 Feb '05

Hi Richard, On Wednesday 16 February 2005 08:45, you wrote: > Windows permits the user to set the name of the windows directory > to whatever he desires. At one time I had directories called > /Win31 and /Win98. Not a common practice, but you may wish to > make provision for this if there are later revisions to the code. > > So the line above might look something like: > > cp "datadir/wine.inf" "$CROOT_WINDOWS/inf/wine.inf" > > if I understand your code correctly. On the other hand, there may be > benefits in having a standard installation designed with a /windows > directory in mind, and the wine user then handles non-standard > installations with whatever skills he has available. wineprefixcreate is executed only if the user calls wine without having a '.wine' directory in place at all. What this means is that there is no registry and no configuration at all at this time. So there is no way that the user has already configured a "/Win98" as the system directory or somesuch. wineprefixcreate is meant to install a default configuration for users who don't have the knowledge or the desire to do so on their own. The configuration it installs is a good starting point to be tailored to your needs, though. It won't be touched by wineprefixcreate again, once it is generated. That said, the line of code you are refering to is not from me. I've only added the call to winecfg. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: [AppDB] edit version and edit notes
by Scott Ritchie 16 Feb '05

16 Feb '05

Cool, I can edit application version info again when I'm a maintainer (and a supermaintainer), however I still can't do it if I'm just a supermaintainer (the only button available in an app version is to resign as supermaintainer.) Furthermore, as a related feature request, listing the names of the supermaintainers in the maintainer field when viewing a version would be useful, so that it appears that a supermaintained app is actually maintained. Thanks for the good work! -Scott Ritchie

2 1

Re: x11drv: make minimizing windows work again
by Vitaliy Margolen 16 Feb '05

16 Feb '05

BTW one side affect of this patch - application icon is not displayed in the task bar anymore. Now it's back to wine's logo. Vitaliy Margolen Tuesday, February 15, 2005, 5:51:34 AM, Vitaliy Margolen wrote: > changelog: > - make minimized windows stay minimized

1 0

Re: x11drv: make minimizing windows work again
by Vitaliy Margolen 16 Feb '05

16 Feb '05

Ok, that semi-helps. Now I don't have an extra window that was showing up after minimize. But programs still don't want to stay minimized. They blink in the task bar and immediately restore themselves. Any suggestions where could it be? People have commented on this before. To reiterate: all programs (that I have) behave in this manner, not staying minimized. Vitaliy Margolen Tuesday, February 15, 2005, 5:51:34 AM, Vitaliy Margolen wrote: > changelog: > - make minimized windows stay minimized

1 0

Re: [NTDLL] Consider SUBLANG_DEFAULT after SUBLANG_NEUTRAL when loading resources
by Dmitry Timoshkov 16 Feb '05

16 Feb '05

"Alex Villacis Lasso" <a_villacis(a)palosanto.com> wrote: > Actually, there was a bug in resource loading, which caused Wine to fail > to load the apropriate resources for my locale (es_EC). As far as I can > tell, the resource loader tries several combinations for the resource > LCIDs, and then defaults to English. In my case, the LANGID was supposed > to be 0x300a (Spanish, Ecuador), and the resources in regedit listed a > resource for LANGID 0x040a (Spanish, DEFAULT language). The loader tried > 0x300a (Spanish, Ecuador), and then 0x000a (Spanish, NEUTRAL). However, > since DEFAULT != NEUTRAL, the Spanish resources failed to be loaded for > my setup, and defaulted to English. > > This patch adds code to try SUBLANG_DEFAULT after SUBLANG_NEUTRAL when > loading resources. This fixes the resource loading for my setup. That's a not correct fix. You either need to add language resources for your locale, or (if you believe that all spanish variants around the world are the same) make spanish translations use LANGUAGE LANG_SPANISH, NEUTRAL instead of LANGUAGE LANG_SPANISH, SUBLANG_DEFAULT -- Dmitry.

1 0

errors compiling wine tests with msvc
by James Hawkins 16 Feb '05

16 Feb '05

Hi, I've been compiling the wine tests with visual studio 2003, and there are a couple errors popping up. One of the errors is that the align modifier is not allowed on function parameters, so most of the test fail to compile with wine's headers because we align most of our data types (AFAICS, I haven't looked through all of our winnt.h): (from wine/include/winnt.h) typedef unsigned __int64 DECLSPEC_ALIGN(8) ULONGLONG, *PULONGLONG; Whereas ms' ULONGLONG does not have the align modifier: (from ms' winnt.h) typedef unsigned __int64 ULONGLONG; Should we reconcile the difference and remove the align from out types? If not the tests won't compile with vs so I guess the other option would be to #pragma disable that warning. Any ideas? -- James Hawkins

3 4

Re: [DSOUND] block align buffer sizes (revised)
by Robert Reif 16 Feb '05

16 Feb '05

Robert Reif wrote: > Make sure buffer sizes are a multiple of the block align size. > Fixed invalid buffer size by rounding up to next multiple of nBlockAlign. Added test to verify buffer rounding behavior. Index: dlls/dsound/buffer.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/buffer.c,v retrieving revision 1.46 diff -u -p -r1.46 buffer.c --- dlls/dsound/buffer.c 11 Feb 2005 11:49:05 -0000 1.46 +++ dlls/dsound/buffer.c 16 Feb 2005 00:55:58 -0000 @@ -1060,9 +1060,14 @@ HRESULT WINAPI IDirectSoundBufferImpl_Cr CopyMemory(dsb->pwfx, wfex, cp_size); - dsb->buflen = dsbd->dwBufferBytes; - dsb->freq = dsbd->lpwfxFormat->nSamplesPerSec; + if (dsbd->dwBufferBytes % dsbd->lpwfxFormat->nBlockAlign) + dsb->buflen = dsbd->dwBufferBytes + + (dsbd->lpwfxFormat->nBlockAlign - + (dsbd->dwBufferBytes % dsbd->lpwfxFormat->nBlockAlign)); + else + dsb->buflen = dsbd->dwBufferBytes; + dsb->freq = dsbd->lpwfxFormat->nSamplesPerSec; dsb->notify = NULL; dsb->notifies = NULL; dsb->nrofnotifies = 0; Index: dlls/dsound/tests/ds3d.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/ds3d.c,v retrieving revision 1.19 diff -u -p -r1.19 ds3d.c --- dlls/dsound/tests/ds3d.c 10 Feb 2005 20:26:20 -0000 1.19 +++ dlls/dsound/tests/ds3d.c 16 Feb 2005 00:56:00 -0000 @@ -713,7 +713,8 @@ static HRESULT test_secondary(LPGUID lpG else bufdesc.dwFlags|= (DSBCAPS_CTRLFREQUENCY|DSBCAPS_CTRLVOLUME|DSBCAPS_CTRLPAN); - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx; if (winetest_interactive) { trace(" Testing a %s%ssecondary buffer %s%s%s%sat %ldx%dx%d " Index: dlls/dsound/tests/ds3d8.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/ds3d8.c,v retrieving revision 1.14 diff -u -p -r1.14 ds3d8.c --- dlls/dsound/tests/ds3d8.c 10 Feb 2005 21:21:13 -0000 1.14 +++ dlls/dsound/tests/ds3d8.c 16 Feb 2005 00:56:00 -0000 @@ -615,7 +615,8 @@ static HRESULT test_secondary8(LPGUID lp else bufdesc.dwFlags|= (DSBCAPS_CTRLFREQUENCY|DSBCAPS_CTRLVOLUME|DSBCAPS_CTRLPAN); - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx; if (has_3d) { /* a stereo 3D buffer should fail */ Index: dlls/dsound/tests/dsound.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/dsound.c,v retrieving revision 1.45 diff -u -p -r1.45 dsound.c --- dlls/dsound/tests/dsound.c 10 Feb 2005 20:26:20 -0000 1.45 +++ dlls/dsound/tests/dsound.c 16 Feb 2005 00:56:01 -0000 @@ -305,7 +305,8 @@ static HRESULT test_dsound(LPGUID lpGuid ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2 | DSBCAPS_CTRL3D; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx; rc=IDirectSound_CreateSoundBuffer(dso,&bufdesc,&secondary,NULL); ok(rc==DS_OK && secondary!=NULL, @@ -573,7 +574,8 @@ static HRESULT test_primary_secondary(LP ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx2; if (winetest_interactive) { trace(" Testing a primary buffer at %ldx%dx%d with a " @@ -672,7 +674,8 @@ static HRESULT test_secondary(LPGUID lpG ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); rc=IDirectSound_CreateSoundBuffer(dso,&bufdesc,&secondary,NULL); ok(rc==DSERR_INVALIDPARAM,"IDirectSound_CreateSoundBuffer() " "should have returned DSERR_INVALIDPARAM, returned: %s\n", @@ -684,7 +687,8 @@ static HRESULT test_secondary(LPGUID lpG ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx; if (winetest_interactive) { trace(" Testing a secondary buffer at %ldx%dx%d " @@ -727,6 +731,53 @@ EXIT: return rc; } +static HRESULT test_block_align(LPGUID lpGuid) +{ + HRESULT rc; + LPDIRECTSOUND dso=NULL; + LPDIRECTSOUNDBUFFER secondary=NULL; + DSBUFFERDESC bufdesc; + DSBCAPS dsbcaps; + WAVEFORMATEX wfx; + int ref; + + /* Create the DirectSound object */ + rc=DirectSoundCreate(lpGuid,&dso,NULL); + ok(rc==DS_OK||rc==DSERR_NODRIVER||rc==DSERR_ALLOCATED, + "DirectSoundCreate() failed: %s\n",DXGetErrorString8(rc)); + if (rc!=DS_OK) + return rc; + + init_format(&wfx,WAVE_FORMAT_PCM,11025,16,2); + ZeroMemory(&bufdesc, sizeof(bufdesc)); + bufdesc.dwSize=sizeof(bufdesc); + bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; + bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec + 1; + bufdesc.lpwfxFormat=&wfx; + rc=IDirectSound_CreateSoundBuffer(dso,&bufdesc,&secondary,NULL); + ok(rc==DS_OK,"IDirectSound_CreateSoundBuffer() " + "should have returned DS_OK, returned: %s\n", + DXGetErrorString8(rc)); + + if (rc==DS_OK && secondary!=NULL) { + rc=IDirectSoundBuffer_GetCaps(secondary,&dsbcaps); + ok(rc==DS_OK,"IDirectSoundBuffer_GetCaps() should have returned DS_OK, " + "returned: %s\n", DXGetErrorString8(rc)); + ok(dsbcaps.dwBufferBytes==(wfx.nAvgBytesPerSec + 4), + "Buffer size not a multiple of nBlockAlign\n"); + ref=IDirectSoundBuffer_Release(secondary); + ok(ref==0,"IDirectSoundBuffer_Release() secondary has %d references, " + "should have 0\n",ref); + } + + ref=IDirectSound_Release(dso); + ok(ref==0,"IDirectSound_Release() has %d references, should have 0\n",ref); + if (ref!=0) + return DSERR_GENERIC; + + return rc; +} + static BOOL WINAPI dsenum_callback(LPGUID lpGuid, LPCSTR lpcstrDescription, LPCSTR lpcstrModule, LPVOID lpContext) { @@ -738,6 +789,7 @@ static BOOL WINAPI dsenum_callback(LPGUI else if (rc == DSERR_ALLOCATED) trace(" Already In Use\n"); else { + test_block_align(lpGuid); test_primary(lpGuid); test_primary_secondary(lpGuid); test_secondary(lpGuid); Index: dlls/dsound/tests/dsound8.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/dsound8.c,v retrieving revision 1.15 diff -u -p -r1.15 dsound8.c --- dlls/dsound/tests/dsound8.c 10 Feb 2005 20:26:20 -0000 1.15 +++ dlls/dsound/tests/dsound8.c 16 Feb 2005 00:56:02 -0000 @@ -38,6 +38,11 @@ static HRESULT (WINAPI *pDirectSoundCreate8)(LPCGUID,LPDIRECTSOUND8*,LPUNKNOWN)=NULL; +int align(int length, int align) +{ + return (length / align) * align; +} + static void IDirectSound8_test(LPDIRECTSOUND8 dso, BOOL initialized, LPCGUID lpGuid) { @@ -315,7 +320,8 @@ static HRESULT test_dsound8(LPGUID lpGui ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2 | DSBCAPS_CTRL3D; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx; rc=IDirectSound8_CreateSoundBuffer(dso,&bufdesc,&secondary,NULL); ok(rc==DS_OK && secondary!=NULL, @@ -594,7 +600,8 @@ static HRESULT test_primary_secondary8(L ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx2; if (winetest_interactive) { trace(" Testing a primary buffer at %ldx%dx%d with a " @@ -693,7 +700,8 @@ static HRESULT test_secondary8(LPGUID lp ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); rc=IDirectSound8_CreateSoundBuffer(dso,&bufdesc,&secondary,NULL); ok(rc==DSERR_INVALIDPARAM,"IDirectSound8_CreateSoundBuffer() " "should have returned DSERR_INVALIDPARAM, returned: %s\n", @@ -705,7 +713,8 @@ static HRESULT test_secondary8(LPGUID lp ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; - bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; + bufdesc.dwBufferBytes=align(wfx.nAvgBytesPerSec*BUFFER_LEN/1000, + wfx.nBlockAlign); bufdesc.lpwfxFormat=&wfx; if (winetest_interactive) { trace(" Testing a secondary buffer at %ldx%dx%d " Index: dlls/dsound/tests/dsound_test.h =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/dsound_test.h,v retrieving revision 1.6 diff -u -p -r1.6 dsound_test.h --- dlls/dsound/tests/dsound_test.h 13 Dec 2004 21:19:02 -0000 1.6 +++ dlls/dsound/tests/dsound_test.h 16 Feb 2005 00:56:02 -0000 @@ -50,7 +50,6 @@ static const unsigned int formats[][4]={ #define TIME_SLICE 31 #define BUFFER_LEN 400 - extern char* wave_generate_la(WAVEFORMATEX*,double,DWORD*); extern HWND get_hwnd(void); extern void init_format(WAVEFORMATEX*,int,int,int,int); @@ -61,3 +60,4 @@ extern void test_buffer8(LPDIRECTSOUND8, BOOL,BOOL,LONG,BOOL,LONG,BOOL,double,BOOL, LPDIRECTSOUND3DLISTENER,BOOL,BOOL); extern const char * getDSBCAPS(DWORD xmask); +extern int align(int length, int align);

1 0

Re: winmm: fix type-conversions
by Robert Reif 15 Feb '05

15 Feb '05

James Hawkins wrote: >Hi, > >msvc picked up a couple type-conversions problems in winmm. > > > >- union { float f; char c[4]; } sample; >+ union { double f; char c[4]; } sample; > sample.f=y; > > A float is 4 bytes and a double is 8. They are not interchangeable. The H/W reads/writes 4 byte floats.

2 1

Re: [winecfg] Change audio detection order
by Michael Stefaniuc 15 Feb '05

15 Feb '05

Paul van Schayck wrote: > My previous patch to do something usefull with multiple detected audio > systems was not accepted. > > But right now ARTS was detected first. I've changed the order to OSS - > ALSA - ARTS - JACK. > > Changelog: > Change detection order to: OSS-ALSA-ARTS-JACK Are you sure you want to prefer OSS instead of ALSA? If you have both that means that OSS runs as emulation on ALSA. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 2

Re: winsock: use local includes in tests
by Maxime Bellengé 15 Feb '05

15 Feb '05

You seems to have forgotten something :) Max On Tue, 2005-02-15 at 15:40 -0600, James Hawkins wrote: > Hey, > > This patch keeps msvc from pulling in msvc system headers when > compiling with wine's headers. > > Changelog > * Use local includes to keep msvc from mixing the system and wine's headers. >

1 0

Re: wine/dlls/user/dde server.c misc.c ddeml16.c d ...
by Pouech Eric DMI AEI CAEN 15 Feb '05

15 Feb '05

are you sure of this? according to MSDN, the iCodepage in convcontext is unicode or ansi depending on the A/W version called for DDE initialize (I never tested it though). A+ > Message du 14/02/05 13:11 > De : "Alexandre Julliard" > A : wine-cvs(a)winehq.org > Copie à : > Objet : wine/dlls/user/dde server.c misc.c ddeml16.c d ... > > ChangeSet ID: 16099 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/02/14 05:53:15 > > Modified files: > dlls/user/dde : server.c misc.c ddeml16.c dde_private.h > client.c > > Log message: > Dmitry Timoshkov > Make DDE implementation always work internally in Unicode. > > Patch: http://cvs.winehq.org/patch.py?id=16099 > > Old revision New revision Changes Path > 1.18 1.19 +42 -72 wine/dlls/user/dde/server.c > 1.25 1.26 +37 -34 wine/dlls/user/dde/misc.c > 1.12 1.13 +1 -2 wine/dlls/user/dde/ddeml16.c > 1.9 1.10 +7 -10 wine/dlls/user/dde/dde_private.h > 1.21 1.22 +32 -60 wine/dlls/user/dde/client.c > > > >

2 1

printf and the long long case
by Jesse Allen 15 Feb '05

15 Feb '05

Since Mike McCormack's printf patch has our own vsnprintf parsing the format strings, but yet we still push integers to libc's printf, I figured that we can handle the 'I' (eye) size type now. I hacked together a patch that handles it and fixes 3 test failures with long long. It fixes it by converting I (eye) and I32 to long, and I64 to long long. 'll' (ell ell) is translated to be long only. Mike, I have a question. You have flags.IntegerDouble++; on the case of long long -- what were you planning on doing with it? Other than that it is unused. I decided to use it as the flag for long long. Patch below. Jesse --- dlls/msvcrt/wcs.c-original 2005-02-14 16:14:01.000000000 -0700 +++ dlls/msvcrt/wcs.c 2005-02-14 17:48:39.000000000 -0700 @@ -378,6 +378,16 @@ sprintf(p, ".%d", flags->Precision); p += strlen(p); } + if( flags->IntegerLength ) + { + sprintf(p, "%c", flags->IntegerLength); + p += strlen(p); + } + if( flags->IntegerDouble ) + { + sprintf(p, "l"); + p += strlen(p); + } *p++ = flags->Format; *p++ = 0; } @@ -474,12 +484,28 @@ { if( *p == 'h' || *p == 'l' || *p == 'L' ) { - if( flags.IntegerLength == *p ) /* FIXME: this is wrong */ - flags.IntegerDouble++; - else + if( flags.IntegerLength != *p ) flags.IntegerLength = *p; p++; } + else if( *p == 'I' ) + { + if ( *(p+1) == '3' && *(p+2) == '2' ) + { + /* Unchecked on 64-bit systems */ + flags.IntegerLength = 'l'; + p += 3; + } else if ( *(p+1) == '6' && *(p+2) == '4' ) { + flags.IntegerLength = 'l'; + flags.IntegerDouble++; /* Why ++? */ + p += 3; + } else { + /* FIXME: 'I' modifier needs to produce + 64-bit number output on 64-bit systems! */ + flags.IntegerLength = 'l'; + p++; + } + } else if( *p == 'w' ) flags.WideString = *p++; else @@ -567,6 +593,8 @@ if( pf_is_double_format( flags.Format ) ) sprintf( number, fmt, va_arg(valist, double) ); + else if ( flags.IntegerDouble ) + sprintf( number, fmt, va_arg(valist, long long) ); else sprintf( number, fmt, va_arg(valist, int) );

2 1

Re: Resend: [Bug 2631] Trap in RegisterClassExA
by Dmitry Timoshkov 15 Feb '05

15 Feb '05

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> wrote: > Make RegisterClassExA check the reserved bytes is a valid value > Tests to confirm this behaviour > + /* Bug 2631 - Supplying an invalid number of bytes fails */ > + cls.cbClsExtra = 0; > + cls.cbWndExtra = -1; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of WndExtra bytes\n"); > + > + cls.cbClsExtra = -1; > + cls.cbWndExtra = 0; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of ClsExtra bytes\n"); > + > + cls.cbClsExtra = -1; > + cls.cbWndExtra = -1; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of ClsExtra and cbWndExtra bytes\n"); You need to set last error to some bogus value (0xdeadbeef usually works) before every API call to ensure that it's really that API call who sets the error. -- Dmitry.

1 0

[ddraw/dsurface/main.c] LPRECT parameters for Main_DirectDrawSurface_Lock
by Andreas Eckstein 15 Feb '05

15 Feb '05

Good morning, wine devs! When playing Icewind Dale II (using wine-20050111), the game sometimes crashed with these messages: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-0x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! or, on another occasion: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-2x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! As you notice, the game tries to lock a surface with width and/or height equal to zero. Frankly I have no idea what the expected behavior is in this case, however playing the critical passages on Windows worked without crash. A quick patch to let Main_DirectDrawSurface_Lock not choke on zero-width or -height LPRECTs solved the problem with wine. Since I don't plan to dig into wine hacking any time soon, could someone merge it into cvs for me (if the new behavior of the function is acceptable, that is)? Thanks in advance! Andreas Eckstein --- The patch: --- dlls/ddraw/dsurface/main.c 2005-01-09 18:35:44.000000000 +0100 +++ dlls/ddraw/dsurface/main.c 2005-02-14 21:03:36.511738080 +0100 @@ -1111,8 +1111,8 @@ (prect->left < 0) || (prect->bottom < 0) || (prect->right < 0) || - (prect->left >= prect->right) || - (prect->top >= prect->bottom) || + (prect->left > prect->right) || + (prect->top > prect->bottom) || (prect->left >= This->surface_desc.dwWidth) || (prect->right > This->surface_desc.dwWidth) || (prect->top >= This->surface_desc.dwHeight) ||

1 0

Re: Fix documentation build
by Alexandre Julliard 15 Feb '05

15 Feb '05

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Those errors are particularly bad as (in the past) it prevented the Wine > documentation on winehq to be built for a release. > > Alexandre, do you build the docs the same way you compile C files after > applying a patch, or is it that your setup allows missing tags? Yes, I always compile the docs, and they build fine on my setup. If you know how to change my config to make it less forgiving I'd be happy to do that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winecfg: various drive detection enhancements
by Paul van Schayck 14 Feb '05

14 Feb '05

On Mon, 14 Feb 2005 16:10:55 +0100, Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Changelog: > Include config.h to reenable reading /etc/fstab on platforms that support it. > Implemented a black list of mount directories, which should not be mapped. > Ensure that the user's home directory is mapped. Hehe I was just about to send a patch doing almost exactly the same things. Including the fix you put in to properply add a drive letter to the working_mask. And are we ready to let wineprefixcreate use winecfg? Or do we want more testing of the autodetect code? Paul

2 1

Re: [OLE #69] Use RPC Runtime
by Mike Hearn 14 Feb '05

14 Feb '05

Robert Shearman wrote: > Hi, > > This patch is significant as it changes the RPC backend of our COM > implementation from using named pipes to using any transport implemented > by the RPC runtime. As a matter of coincidence, this patch is numbered > 69, which is my favourite number, and this patch is my favourite patch. Haha, 69 DUDE!!!! > Not only this, but it should also solve some real problems with having > way too many threads (one and only one per apartment) and some complex > deadlocking situations caused by this. It also significiantly reduces > the amount of code in the file and reduces most of it to simple wrappers > around the RPC runtime functions. We'll still need to run a message loop in the RPC runtime right? Until we do that I think InstallShield won't work correctly. So that's the keystone - after that it should all fall into place. thanks -mike

2 1

Real-world appdb
by Holly Bostick 14 Feb '05

14 Feb '05

If I may interrupt and split off the various theoretical discussions about recoding the appdb, I'd like to report my experiences actually using the appdb as it is today. I wanted to use the appdb in order to (attempt to) solve some installation problems with several applications (two games, two applications). My impressions as a user predisposed to feeling that the appdb is an extremely useful capability, currently (severely) underutilized, were as follows: I started with the last program I had tried to install, the expansion pack for Icewind Dale, called "Heart of Winter". It's been some time since I've even accessed the appdb, much less tried to use it to solve a problem with a listed program, so I had a fairly fresh eye for how it looks, how accessible the information I needed was, and how noticeable useful information that I didn't know I needed was (or was not). I had forgotten the precise URL directly to the appdb, so I had to start from the main site, which brings me to my first useability complaint: too long a trail to get to the app I'm looking for. I had to go through 4 links just to get to the main application page. First, the sidebar link from the main site to the appdb front page. This front page is useless to me (and imo, fairly useless overall), since the majority of the "Gold" and "Silver' apps so prominently listed I already do/would use the native alternatives for in the case of winzip, p7zip, Paint (Paint??! it's barely useful under Windows!), SimCity, IE, Excel, ACDSee, Money, Frontpage/Dreamweaver, and Ant Movie Catalog. Others I do not use at all, either because I have no use for them, in the case of Powerpoint, Access and Visio, or because they are "special interest programs" as in the case of Warcraft and Age of Empires (I play games, but not those). Having a lovely page with big 'ol screenshots is very nice and all, but given that the chance of a random individual user coming to use the appdb actually needs to know about those particular programs (as opposed to one or more of the thousands of others they may be attempting to run) is relatively small, I would think that the "Top 25" links would be more useful there (and less space-consuming, since I have to scroll the current page to see if there might be a useful link at the bottom of it), along with another, more prominent "Browse Categories" link than this page as it stands. So, after following the first link to a page I cannot use, I must then link to "Browse apps" to get a category listing (Games), and then to the sub-category page (if present, which in this case it was; Role-Playing), and then to the application itself to see the results for Icewind Dale ( http://appdb.winehq.org/appview.php?appId=141 ). I am now quite tired, having trudged through all these links when I was already tired; after all, the only reason I'm at the appdb at all is because I have tried to install an application and failed, which is stressful-- especially since I, like many users, have retried the process several times before looking to the appdb for help. And yes, I could have used the search box, but that would be *typing* :-) when I was mousing. Yes, it's my worst leftover habit from my years of Windows use; I tend to mouse and not type. But I'm far from alone in this, so it's a fair comment. My first impressions on arrival (since I was looking at the page with "fresh eyes"): 1.1) The current design of the individual application page is readable and easy on the eyes. 1.2) The "Description" area is well-placed and sized, but the information contained therein is generally pointless and should be a "Summary" instead. Most of the descriptions I read told me what the application is and does as if I was making a buying decision. However, I believe that in most cases (certainly my case), users are already familiar with the capabilities of the program itself (since they already have it), thus telling users what a program they already have actually does is a waste of space. What I would have found more useful on what is essentially the "overview" page is some indication as to whether the problems with the application that I am consulting the app database about are known, and whether they are solveable (so I'd know whether to continue with the appdb or if I need to immediately begin searching elsewhere for solutions). A nice bulletted list (or a couple of them) would do just fine: "Installs: Yes, no, with modification (the last being a link to the comment explaining the needed modifications); "Runs: Yes, no, with modifications (as above); "Known Problems: Bulleted list (with links), none". If such a summary was provided on the main application page, I would not mind so much having to go to yet another page (fifth link, now) in order to find specific details on possible issues with the particular *version* of the program I'm trying to install/run. 1.3) The screenshot on the application overview page is some reward, however; at least I have proof that the application can be made to work, even if I cannot get it to, and its placement is eye-catching so that I am sure to be a bit heartened by seeing it. 1.4) The big "Become a super maintainer" link/button is nice, and encourages me to become one (via guilt; because I'm attempting to look up programs I very commonly install under Wine whenever I install a new distribution, I feel I might be familiar enough with the issues surrounding them that I should contribute something back) but I do not become a maintainer because: 1.4a) I couldn't log in via that login button anyway; I had to use the side menu link and then go back to the page I was on. Fortunately the "send a new password" link on the login page that the "Log in to become a maintainer" button takes you to didn't seem to work either, so I was able to look up my original password in a password maintenance progam (PCMagazine's 6-year-old Password Prompter) that I run via Wine (which is why I hadn't so much bothered to stop what I was doing and look it up in the first place) and use my real login in the side menu link instead; 1.4b) more importantly, I do not know what the responsibilities of a "maintainer" are-- much less a "super maintainer". There is no link on that page as to what this means (not even a little question mark with a tooltip popup), and no indication as to whether actually clicking the button will go to an "intermediate" page which explains what it is, or just sets your login as the maintainer for this app (since I have specifically had to log in in order to enable this button in the first place, it's not an unreasonable assumption that that might occur). Since I didn't know what would happen, and didn't know if I wanted to or was capable of fulfilling what might be a committment (how much do I need to know about the program? How much do I need to know about programming? Do I need to have a version of Windows available to know how the program runs there, so I can compare it to how it runs under Wine?), I did not click the button, so the apps will remain unmaintained for the time being (or they won't be maintained by me, anyway). Weirdly enough, going to the version page for the application offers me the opportunity to be a "regular" maintainer-- so, what, that means I would be a maintainer for that specific version, whereas "super maintainer" means that I'd be maintainer for all versions, like some kind of 'team leader'? I'm not sure that either makes sense to me as a user, nor that it is a logical setup generally, at least for games, which usually should not be run at lower versions if a patch (which increases the version while repairing errors) is available. So there is in some ways no reason to maintain version "1.0" when no one should actually be *running* version 1.0 other than immediately after install, and then only for the 5 seconds before the user has installed one or more patches (after which they will be running a higher version). There are certainly some games that would require that several patch levels/versions be maintained; I know of at least one (Settlers 3) that only works (for my boyfriend under Windows 2000) with a lower patch than the "latest" patch, and SiN (a game which I run under Wine despite a native version being available, because I already have two copies of the Windows version) is also very touchy about patches, so it certainly can happen that multiple patch levels of a game might need to be separately maintained. I would think that the game's maintainer would know if his/her particular charge needed special circumstances though, and since this is not a common situation (you usually want all users to be running the latest patch, and this is usually a good idea), having it as a general organizational strategy, at least in the games category, seems to be unnecessary work. 1.5) Comments are not being counted properly on the main overview page; Icewind Dale actually has two comments on the version page (version 1.0, which again is not the "real" version as there are two expansion packs, both of which contain patches that increase the version number, and these patches are also available separately, so no one should be using "vanilla" 1.0), but the main page says that the number of comments are 0. 1.6) I hope that one of the responsibilities of the maintainer or super maintainer is to control comments in some way. I completely understand that users of the appdb who are having problems with any given app *have no other place to state their issue with the specific program in an organized and somewhat reliably maintained fashion* (as wine has no forums, and certainly no forums linked to the specific app). However, comments like "hmm... when exporting registry, the reg file is all messed up. It has weird symbols in it. Any idea what I'm doing wrong?" have no place in the appdb. On the other hand, if I was the maintainer, I would want to know that a user of the app that I maintained was evidencing this problem (assuming that the issue commented on is specific to the app, which in this case it probably is not), and help the user solve it so that I could update the procedure to install and run the app. I'd really like to see forums or at least some kind of PM system so that the users of the applications could reliably communicate with the maintainer for the benefit of both parties. I see that Planescape: Torment (another game I have running under Wine, without issue; http://appdb.winehq.org/appview.php?versionId=437 ) has a maintainer, but his name is not a mailto: link, so I can't contact him (afaik) to advise him of any new information I may have discovered short of posting a comment myself... which is fine if it's new information (assuming that my comment fits into the organizational structure of the db so that following users can find it easily), but if it's an app-specific issue that I want his help with, it's a waste of space (insofar as such a comment provides no real information to other users searching the database except a confirmation of the issue), and the appdb as it is gives no assurance that the maintainer will see the comment anyway. Comments should also require the specification of the Wine version, the distribution under which it is used, and the type of install (self-compiled from source, distribution repository package, or Wine distribution package; I have visions of a radio button) to be attached to the comment, as new users often don't know to include this information, but it's pretty hard to answer many questions without having this information (so one has to ask, which wastes time and space). A Wine FAQ at the forefront of the appdb, or even linked to each application's overview page might be nice, too, for more general issues like the above comment-- an explanation of basic procedures such as exporting/importing registry entries, what common errors mean, like the "Warning: The specified Windows directory L"C:\\Windows" is not accessible" error and what to do about it, why not to get all freaked out by seeing "fixme"s, and simple statements like the fact that some programs will run fine with wine /path/to/app.exe, but some will fail that way with very scary looking errors, but will run fine if one first cds to /path/to/ and then runs wine app.exe. This kind of thing is often something new Wine users don't know, but is a very simple way to eliminate possible vectors of error before going to any mailing list or forum with problems, and may eliminate the need for a user to ask for help at all (as the program works when started in the alternate manner). Somebody's going to say I should write a FAQ myself and submit it as a patch, aren't they? Yes, OK, but let me finish this mail first ;-) . 1.7) Descriptions are really not very useful, for several reasons. Still focusing on Icewind Dale (since that's the page I have open in the appdb atm), here's the Description for the version page: "Description CD Release. Runs from a modified Baulders Gate engine. Notes from that game would help here as well." But there's no link to said notes, nor are the relevant notes copied from that page and posted as an addendum, so even though this particular description does contain some useful information (for once), it's not even a lead, but only a suggestion of a lead. Big help. 1.8) (or, "On the road again") Off to the Baldur's Gate page, then... Back button to the subcategory (Games=>Role-Playing; thank heavens they're the same type), follow a new link to the Baldur's Gate page... I'm ranging far afield now, but in this case, that's OK. I have BG as well, but haven't installed it yet, so it's useful for me to look at the page anyway. Luckily. Because if I didn't have BG, I would now be traveling to the page of a completely different application in which I had no interest, with no assurance that what I find there will be of any use to me. In that case, I'd probaly be pretty bloody pissed off by now, given that I would have spent a fair amount of time trailing around the appdb without being so much as a single step closer to solving my actual problem with the original application, or even having it confirmed as a known problem, or receiving a clue that implied "user error", or anything whatsoever that would give me a troubleshooting or solution trail. http://appdb.winehq.org/appview.php?appId=157 if you'd like to come with me. 1.9) (or, "Helpful help?") Well, there are helpful notes there on the BG page, or rather, actual solutions to potential problems that I might have were I installing BG, which I remind you that I am not. Mind you, I, a simple user, don't know if the solutions posted for Baldur's Gate are problems that also exist under Icewind Dale -- well, actually, I personally do know, because I have run IWD and IWD2 under Wine in the past, and am currently running Planescape: Torment, (which btw runs great under 20050111 without any modification to Wine dlls, one appdb-documented change to the game's configuration file, and one small, optional [AppDefault] in Wine's config). All 5 of these games (IWD, IWD2, BG, BG2, and Planescape) are made by Black Isle, use more or less the same engine, and evidence similar problems to each other. But this does not mean that "your average user" would have any experience with multiple Black Isle games and thus know their technical similarities and differences. The solutions on the Baldur's Gate page are general enough to be worth trying if IWD did not run at all, or ran poorly. However, this is not my problem; IWD installs perfectly and seems to run quite well (except for one minor but annoying issue related to Managed or Desktop settings that I haven't yet idenitified how to fix, since the way I fixed the same issue for Planescape doesn't seem to work here). Thus, none of the listed issues for Baldur's Gate is related to my actual problem with Icewind Dale, the specific application I have trailed all over the appdb trying to fix-- and the foremost reason is that my problem is not with IWD itself, but with installing the the expansion pack, "Heart of Winter", and 1.10) *this application is not listed in the appdb*, either as a version of IWD (since installing the expansion does require IWD, and does patch the original to a higher version), or as a separate program. Also not listed are the Baldur's Gate expansion, "Tales of the Sword Coast", and the Baldur's Gate 2 expansion "Throne of Bhaal", so I hope I have no trouble installing those expansion packs when I get around to it. However, given that I am already unable to install the expansion pack for IWD, and since I know that IWD and Baldur's Gate are strongly related, I'm expecting the worst-- and since the appdb is unable to help me with IWD: Heart of Winter (nothing said about the official, free, downloadable final expansion, Trials of the Luremaster, which is also not in the database), if I hit trouble, I already know where I *won't* find any help. Fine, I'm stopped cold with this issue, let's stop quickly by the Icewind Dale 2 page ( http://appdb.winehq.org/appview.php?appId=1033 ) and see if there's help for me there; the issue being that it won't begin the install. InstallShield fails to extract/open with a regular Windows-type dialog saying either that some dll in the /tmp/{long CLSID-looking-string-of-numbers} folder can't be opened, or that IKernel.exe can't be run. Actually the same issue I'm having when trying to install IWD:HoW, which doesn't surprise me very much, as I would guess that the Installshield for IWD:HoW and IWD2 are more closely related to each other than the one for the original IWD. Since the issues seem similar, maybe there's a fix for both apps on the IWD2 page. 2.1) Only one version (the original version, although there is a 2.01 patch), but whatever; according to the description, I am supposed to be able to install this, as long as I have an insanely old version of Wine (the original description was penned by someone installing under 20020904!), which I don't. 2.2) Two comments listed on the overview page, only one comment in actuality. 2.3) I'll try the workaround listed in the description, but since the version of Wine used is so distant from what I actually have, and the error which the workaround is fixing may or may not be the same one I'm having (it's impossible to tell), and furthermore may not even be needed anymore given the improvements in Wine in the meantime, I don't have much hope that it will work. But it's the only lead I have, as far as the appdb is concerned. Given that my second-best source of information--Transgaming's games database and forums-- has been blown away and replaced with a new games database (for which little or no data for most individual games has yet been entered), I don't have many other options than the appdb, since sites like Frank's Corner only cover a very limited selection of apps/games, and the various IWD sites on the Web don't cover Linux). If the workaround doesn't work, I will probably dig up my backup of my last installed and updated Win98-- which I cleverly saved all the system files from before blowing it away, for just such an eventuality-- and "taint" my Wine installation by copying over the "real" InstallShield files to the fake windows Common Files. This will probably work-- it has in the past-- but I was really hoping to run 'pure' Wine this time around. It has so been improving by leaps and bounds lately. Let's see if things are any better in the Applications section. My issue here is that I need to burn some CloneCD images. K3b claims they are unuseable, and ccd2iso did not create recognizeable isos from them. It remains unclear whether this is because the images themselves are no good, or because there is a problem with ccd2iso, which several users claimed was the case on the project site's bug tracker ( http://sourceforge.net/tracker/?group_id=94638&atid=608541 ). So I want to install either CloneCD (preferred), or Nero (version 6 or above, which I *think* will also recognize the images, I have version 5.* as well, but I don't *think* it will solve my problem to install it, as I'm not sure when Nero's recognition of *.ccd images became reliable, but I believe it was with version 6, if in fact it is reliable at all), to see if the error is in the images themselves, or burn them if the problem is with K3b. I do not have any real interest in installing these programs on their own account, although if I kept one, I would keep CloneCD for the specific use of handling .ccd images, on the rare occasion that I need to deal with them. I would prefer not to install Nero at all, and certainly not to keep it, as it's too much overhead for the only use I have for it (for my normal requirements, K3b is perfectly adequate). The only reason Nero is under consideration at all is that I may not be able to install or use CloneCD and Nero is the only other application that I know that might reliably recognize and burn the images if they are in fact not flawed. I have already tried to install both programs; CloneCD installed without problems, but would not run, starting the debugger immediately with an error in the 32-bit code-- I would like to find out why, and if there is a solution. I then tried to install Nero 6.3, but clicking either the Nero 6-only setup button or the "install suite" button on the autorun dialog blinked and returned me to the autorun dialog-- I'd like a solution, if I cannot get CloneCD to run (which I don't think I can). This is a real issue I am attempting to solve, and my goals are clear. I am now going to the appdb to see if it will help me. 3.1) Gotta search for CloneCD, as I have no idea what category it would be in. Utilities=>File System, it turns out. Guess that makes sense, no idea if it's "intuitive". http://appdb.winehq.org/appview.php?appId=822 3.2) Version: not the version I have, but any port in a storm... Comments field says there's one comment. Also not a hopeful sign, but the appdb has been wrong about the comments before, and anyway, any port.... 3.3) ..what the..???!!! There is no comment! Is the description being counted as a comment? In any case, there is absolutely no information whatsoever for this application (I don't call "Description: Program for burning CD Especially to make clones of original CD\'s" information), and there are Zarro bugs found in Bugzilla (of course; I'm not even certain if Bugzilla is even linked to and indexed with the appdb in that way yet). OK, this is a dead end. Guess I'd better try to fix Nero, so it's off to http://appdb.winehq.org/appview.php?appId=152 . 4.1) Hey, the first app I've looked at in this db with a "native alternative" link. Nice, but I'm not reading the description anyway (I know what Nero Burning ROM is and does), so I almost missed it. I think that the link should be underneath the link to the Nero URL, above the screenshot (one extra field, thus; "Native Alternative <link to K3b>"). I'd be much more likely to see it then (if I didn't know about K3b already). 4.2) Versions: all versions that an 'ordinary' user might have are represented, good; no comments counted for any of them, bad (if true). Following the link to 6.x. 4.3) Nope, there are in fact no comments. And the description field is exactly the same, except without the native alternative link. What is the point of that? It's Nero version 6, one can reasonably assume that the program has not suddenly changed from the CD-burning application described on the overview page to a word processor, so why not at least put the changelog here.... oh, right, because we're not trying to sell Nero, which would be the only reason to put Nero's changelog in this field. It becomes much clearer now why the "Description" field is useless, and should be replaced by a "Summary" of whether this version of this application works in any way under Wine, and then the comments could/should contain solutions to the specific common problems a user might encounter when trying to install or run this (version of the) program. As it is, there's nothing for me here; let's see if version 5.x is any better. 4.4) huh, 7 comments, when none are counted on the overview page. 4.5) Two comments look like they might be helpful if I have problems attempting to install an earlier version of Nero (which I may have no choice but to attempt, since the appdb has no assistance for my preferred version of Nero, or my preferred application, CloneCD). 4.6) The most useful snippet on this page is the mention of Frank's Corner (without a link, but I know where it is), where I would next go to see if I can find some adequate instructions/help/guidance for one or both of these programs (not to mention IWD and IWD2). In actual fact, what I will probably do is transfer the CloneCD images to my boyfriends Windows PC, install CloneCD there, and burn them that way. It's a pain, but ultimately faster and easier than trying to find any organized assistance on these programs via the appdb. Which is just a bloody shame, imho. Anyway, I'm terribly sorry this was so long, but it seemed past time to offer some input on actual useability issues in the midst of all this discussion. The appdb does "work" as it is (I can navigate it, read the entries, etc); I assume that it will "work" when/if adjusted, both in terms of code, and with the addition of active maintainers. But it is barely of any *use* whatsoever as it is, and it's not clear to me whether the proposed redesign and/or increasing numbers of active maintainers will improve the db's practical functionality for users, for whom I feel this complex and difficult to maintain database should be a primary resource, from which they can both receive and offer assistance in an organized fashion. Or have I misunderstood the function of the appdb entirely? Holly

8 15

TechBot
by Ivan Leo Puoti 14 Feb '05

14 Feb '05

Hello list, the #reactos channel has a thing called techbot that translates NTSTATUS and GetLastError() values from their numeric value to their meaning, I think it would be useful to have it in #winehackers, any objections? Ivan.

1 0

Re: Compiling MFC with Winelib
by Ira Krakow 14 Feb '05

14 Feb '05

An excellent idea! I definitely want to include a section on compiling the MFC with Winelib in the book. From what I can see, it looks like a big part of it is compiling stdafx.h and generating precompiled headers. A nice enhancement would be for winemaker to sense that it's working with MFC sources and to generate the appropriate flags. Do you have any preliminary examples or documentation that goes beyond the current docs? It would help my experimentation. Thanks. Ira

1 0

winetest on wine and todo_wine
by Paul Vriens 14 Feb '05

14 Feb '05

Hi, in shlwapi/tests/shreg.c I've put two todo_wine statements for obvious reasons (they fail, so do not test). If I however look at http://test.winehq.org/data/200502101000/wine_98/shlwapi:shreg.txt These tests are executed! Any ideas what could be wrong? If I execute the tests on my Wine box the tests are skipped. Cheers, Paul Vriens.

5 7

Re: working installshield?
by Mike Hearn 14 Feb '05

14 Feb '05

Marcus Meissner wrote: > Hi, > > Is there any chance to have a working installshield at some time? > > I don't really want to fall back to the december or even earlier WINE > releases for our spring SUSE Linux product ;) Rob has a patch that should (touch wood) fix the remaining issues. I'm not sure when he is going to submit it but it looked pretty complete last time I saw it. We may also need to adjust the RPC runtime so that it runs a message loop (for re-entrancy), but I don't think that'd be too hard. So, maybe a week or two? It certainly should not be broken for more than month. thanks -mike

1 0

Re: working installshield?
by Marcus Meissner 14 Feb '05

14 Feb '05

And actually this should have gone to wine-devel... > Hi, > > Is there any chance to have a working installshield at some time? > > I don't really want to fall back to the december or even earlier WINE > releases for our spring SUSE Linux product ;) > > Ciao, Marcus

1 0

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