June 2005 - Wine-Devel - list.winehq.org

Problems in bitblt (in x11drv)
by David Albrecht June 9, 2005

June 9, 2005

Sorry about the resend, but I used an old copy of the source inadvertently. I'm new to wine and relatively new to windows programming being mostly a unix hack. Just for yucks I thought I'd get a relatively simple app emu48 to work. Turns out emu48 is not so simple (multi-threaded, etc.). First task towards functionality is to get the boot up display to look right and a BitBlt didn't seem to be functioning correctly. Much investigation later it turns out that in the file dib.c: /* if the source bitmap is 8bpp or less, we're supposed to use the * DC's palette for color conversion (not the DIB color table) */ is NOT true at least not for my case where the DC containing the bitmap has one palette and the colormap for the bitmap is not the same. If I disable the hPalette tests as I did below and always use the DIB colormap it boots up with the correct display otherwise the color mapping doesn't match the DIB bits and I get garbage. if (dib.dsBm.bmBitsPixel <= 8) { HPALETTE hPalette = GetCurrentObject( physDevSrc->hdc, OBJ_PAL ); if (/*!hPalette || (hPalette == GetStockObject(DEFAULT_PALETTE))*/1) { /* HACK: no palette has been set in the source DC, * use the DIB colormap instead - this is necessary in some * cases since we need to do depth conversion in some places * where real Windows can just copy data straight over */ colorMap = physBitmap->colorMap; nColorMap = physBitmap->nColorMap; } else { colorMap = X11DRV_DIB_BuildColorMap( physDevSrc, (WORD)-1, dib.dsBm.bmBitsPixel, (BITMAPINFO*)&dib.dsBmih, &nColorMap ); if (colorMap) aColorMap = TRUE; } } Not knowing the full ramifications of this code I thought I'd pass this along so that someone more familiar with it can reassess it. The DC and bitmap are created thusly (nLcdDoubled == 2): #define B 0x00000000 #define W 0x00FFFFFF #define I 0xFFFFFFFF static struct { BITMAPINFOHEADER Lcd_bmih; DWORD dwColor[64]; } bmiLcd = { {0x28,0/*x*/,0/*y*/,1,8,BI_RGB,0,0,0,64,0}, { W,B,B,B,B,B,B,B,B,B,B,B,B,B,B,B, B,B,B,B,B,B,B,B,B,B,B,B,B,B,B,B, I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I, I,I,I,I,I,I,I,I,I,I,I,I,I,I,I,I } }; VOID CreateLcdBitmap(VOID) { // create LCD bitmap _ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4); bmiLcd.Lcd_bmih.biWidth = LCD1_ROW * nLcdDoubled; bmiLcd.Lcd_bmih.biHeight = -64 * nLcdDoubled; hLcdDC = CreateCompatibleDC(hWindowDC); _ASSERT(hLcdDC != NULL); hLcdBitmap = CreateDIBSection(hLcdDC, (BITMAPINFO*)&bmiLcd,DIB_RGB_COLORS, (LPVOID*)&pbyLcd, NULL, 0); _ASSERT(hLcdBitmap != NULL); hOldLcdBitmap = SelectObject(hLcdDC, hLcdBitmap); _ASSERT(hPalette != NULL); SelectPalette(hLcdDC, hPalette, FALSE); // set palette for LCD DC RealizePalette(hLcdDC); // realize palette UpdateContrast(Chipset.contrast); } In the new source update contrast doesn't do a SetDIBColorTable it just plays with the pattern used to write to the dib. static DWORD Pattern[16]; VOID UpdateContrast(BYTE byContrast) { DWORD c = byContrast; DWORD b = byContrast + 0x20; if (bmiLcd.dwColor[b] == 0xFFFFFFFF) b = 0; _ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4); if (nLcdDoubled == 1) { WORD i,j; for (i=0; i<16; ++i) { Pattern[i] = 0; for (j=8; j>0; j>>=1) { Pattern[i] = (Pattern[i] << 8) | ((i&j) ? c : b); } } return; } c = (c<<8) | c; b = (b<<8) | b; if (nLcdDoubled == 2) { Pattern[0] = (b<<16)|b; Pattern[1] = (b<<16)|c; Pattern[2] = (c<<16)|b; Pattern[3] = (c<<16)|c; return; } c = (c<<16) | c; b = (b<<16) | b; if (nLcdDoubled == 4) { Pattern[0] = b; Pattern[1] = c; } return; } The BitBlt: static BYTE Buf[36]; VOID UpdateMainDisplay(VOID) { UINT x, y, nLines; DWORD d = Chipset.start1; BYTE *p = pbyLcd; #if defined DEBUG_DISPLAY { TCHAR buffer[256]; wsprintf(buffer,_T("%.5lx: Update Main Display\n"),Chipset.pc); OutputDebugString(buffer); } #endif _ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4); if (!Chipset.dispon) { nLines = 64; ZeroMemory(pbyLcd, LCD1_ROW * nLcdDoubled * nLines * nLcdDoubled); } else { nLines = LINES(Chipset.lcounter); // main display lines if (nLcdDoubled == 4) { for (y = 0; y < nLines; ++y) { Npeek(Buf,d,36); for (x=0; x<36; x++) { *(((DWORD*)p)++)=Pattern[Buf[x]&1]; *(((DWORD*)p)++)=Pattern[(Buf[x]>>1) & 1]; *(((DWORD*)p)++)=Pattern[(Buf[x]>>2) & 1]; *(((DWORD*)p)++)=Pattern[(Buf[x]>>3) & 1]; } CopyMemory(p, p-LCD3_ROW, LCD3_ROW); p+=LCD3_ROW; CopyMemory(p, p-LCD3_ROW*2, LCD3_ROW*2); p+=LCD3_ROW*2; d+=Chipset.width; } } if (nLcdDoubled == 2) { for (y = 0; y < nLines; ++y) { Npeek(Buf,d,36); for (x=0; x<36; x++) { *(((DWORD*)p)++)=Pattern[Buf[x]&3]; *(((DWORD*)p)++)=Pattern[Buf[x]>>2]; } CopyMemory(p, p-LCD2_ROW, LCD2_ROW); p+=LCD2_ROW; d+=Chipset.width; } } if (nLcdDoubled == 1) { for (y = 0; y < nLines; ++y) { Npeek(Buf,d,36); for (x=0; x<36; x++) *(((DWORD*)p)++)=Pattern[Buf[x]]; d+=Chipset.width; } } } EnterCriticalSection(&csGDILock); // solving NT GDI problems { BitBlt(hWindowDC, nLcdX, nLcdY, 131*nLcdDoubled, nLines*nLcdDoubled, hLcdDC, Chipset.boffset*nLcdDoubled, 0, SRCCOPY); GdiFlush(); } LeaveCriticalSection(&csGDILock); return; } As emu48 still doesn't work I'll probably have more things I find in likely much different areas later. Dave

2 2

Re: Add a couple of CloseHandle calls
by Alexandre Julliard June 9, 2005

June 9, 2005

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > (is this file supposed to have 2002 as a copyright year?) Yes, that's when I wrote it. It only took me 3 years to get around to making the code pass the tests ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Alpha Status ?
by Tom Wickline June 9, 2005

June 9, 2005

Hello All, Can we change Wine from Alpha to Beta Status? Or is this scheduled for the 0.9 release ? Tom

1 0

Re: wcmd: Remove user32 dependencies
by Marcelo Duarte June 9, 2005

June 9, 2005

James Hawkins escreveu: >Hi, > >This patch is in responese to Bug #1982 'Can't SSH into a computer and >use "wine cmd" or wineconsole' > >http://bugs.winehq.org/show_bug.cgi?id=1982 > >The problem as identified by Marcus is that wcmd is importing user32 >which brings in the x11 driver causing the ssh'ed wcmd to fail: > >(~)> wine cmd >x11drv: Can't open display: > > The command "wine wcmd" or "wcmd" produces to me the same results and I do not see the errors described in bug1892. Only the keyboard input is bad, but the message above is not displayed to me. The command "wineconsole wcmd" functions. My terminal is 80x50 and it display on top 40x50. >I couldn't figure out any other way to get rid of LoadString. It's >pretty essential since we're loading multilingual help strings from >resource files. > >Changelog >* Dynamically call LoadString from user32. >* Remove all direct user32 dependencies. >* Don't import user32. > > > I dont think that this is necessary. This is not the cause of bug 1892. Maybe export DISPLAY

1 0

Re: Remove user32 dependencies
by Dmitry Timoshkov June 9, 2005

June 9, 2005

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * Dynamically call LoadString from user32. > * Remove all direct user32 dependencies. > * Don't import user32. > --- programs/wcmd/Makefile.in 9 Mar 2004 04:54:07 -0000 1.22 > +++ programs/wcmd/Makefile.in 9 Jun 2005 00:20:31 -0000 > @@ -4,7 +4,7 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = wcmd.exe > APPMODE = -mconsole > -IMPORTS = shell32 user32 kernel32 > +IMPORTS = shell32 kernel32 wcmd still indirectly depends on user32 due to the fact that shell32 imports user32, and that's unavoidable. -- Dmitry.

1 0

Re: [msvcrt] Implement %I types for printf
by Alexandre Julliard June 9, 2005

June 9, 2005

Jesse Allen <the3dfxdude(a)gmail.com> writes: > @@ -191,11 +191,14 @@ > } buf; > } pf_output; > > +#define INTEGERSIZE_LONG 1 > +#define INTEGERSIZE_LONGLONG 2 > + > typedef struct pf_flags_t > { > char Sign, LeftAlign, Alternate, PadZero; > char FieldLength, Precision; > - char IntegerLength, IntegerDouble; > + char IntegerLength, IntegerDouble, IntegerSize; The IntegerDouble field was supposed to be used for that already, no need to add another one. > @@ -384,6 +387,16 @@ > sprintf(p, ".%d", flags->Precision); > p += strlen(p); > } > + if( flags->IntegerLength == 'I' ) > + { > + sprintf(p, "l"); > + p++; > + } > + if( flags->IntegerSize == INTEGERSIZE_LONGLONG ) > + { > + sprintf(p, "l"); > + p++; > + } This assumes that the system printf supports %ll formats, that's not portable. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: MSI: action.c more RegisterProduct work
by Mike McCormack June 9, 2005

June 9, 2005

Aric Stewart wrote: > @@ -6033,6 +6042,21 @@ > size = strlenW(buffer)*sizeof(WCHAR); > RegSetValueExW(hukey,szProductName,0,REG_SZ, (LPSTR)buffer,size); > HeapFree(GetProcessHeap(),0,buffer); > + > + buffer = load_dynamic_property(package,szProductLanguage,NULL); > + size = sizeof(DWORD); > + langid = atoiW(buffer); > + RegSetValueExW(hukey,szLanguage,0,REG_DWORD, (LPSTR)&langid,size); > + > + buffer = load_dynamic_property(package,szARPProductIcon,NULL); > + if (buffer) > + { > + LPWSTR path; > + build_icon_path(package,buffer,&path); > + size = strlenW(path) * sizeof(WCHAR); > + RegSetValueExW(hukey,szProductIcon,0,REG_SZ, (LPSTR)path,size); > + } > + > FIXME("Need to write more keys to the user registry\n"); > > hDb= alloc_msihandle( &package->db->hdr ); Since load_dynamic_property allocates memory, you leak "buffer" here twice... Mike

1 0

Re: Combine WINE_WAVEOUT and WINE_WAVEIN into single structure
by Robert Reif June 8, 2005

June 8, 2005

Jeremy White wrote: > This combines the WINE_WAVEOUT and WINE_WAVEIN structures into > a single WINE_WAVECOMMON structure, as most of the fields were > duplicated anyways. This patch should not change any > functionality, but will allow for some elimination > of duplicate code in an upcoming patch. > > (Credit Alexandre for suggestion the combination into a single > structure). > >+} WINE_WAVECOMMON; > > Could you call it WINE_WAVEDEV or WINE_WAVEDEVICE?

1 0

dlls/shell32/shv_item_cmenu.c regression
by Gerald Pfeifer June 8, 2005

June 8, 2005

After last night's updates, I'm no seeing the following warning in dlls/shell32/shv_item_cmenu.c shv_item_cmenu.c:203: warning: assignment discards qualifiers from pointer target type The last two changes to this file were revision 1.32 date: 2005/06/07 20:30:30; author: julliard; state: Exp; lines: +1 -1 Warning fixes for -Wmissing-declarations and -Wwrite-strings. ---------------------------- revision 1.31 date: 2005/06/06 19:50:36; author: julliard; state: Exp; lines: +3 -3 Make remaining OLE interface vtables const. and I'm pretty sure it's the latter (revision 1.32) which causes this problem. Would you mind fixing this? Thanks, Gerald

1 0

Re: Asynchronous Named Pipes
by Uwe Bonnes June 8, 2005

June 8, 2005

>>>>> "Robert" == Robert Shearman <rob(a)codeweavers.com> writes: Robert> Hi, This patch depends on "Small RPC Bug Fixes" for the ole32 Robert> tests to pass. I hope people don't think of me as a PITA, but here again my RFT (Request for Tests): Rob, can you please add a testcase in dlls/kernel/tests/pipe.c showing the usage and the functionality of your patch? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Tests and window versions
by Paul Vriens June 8, 2005

June 8, 2005

Hi, I've just finished another test for NtQuerySystemInformatio. In this test I test the structure SYSTEM_PROCESS_INFORMATION. The structure is however different for NT4. If I add an osversion (> 4) check I can check the structure for W2K/WinXP and W2K3 and skip this structure-check for NT4 (for now). Wine however defaults to Win98 unless I put in the config: [AppDefaults\\ntdll_test.exe.so\\Version] "Windows" = "winxp" Is there another approach or will this test be accepted as is ? Cheers, Paul.

2 1

Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-02b.diff]
by Alexandre Julliard June 8, 2005

June 8, 2005

"Gerold J. Wucherpfennig" <gjwucherpfennig(a)gmx.net> writes: > --- dlls/cabinet/cabinet.h 14 May 2005 11:06:10 -0000 1.12 > +++ dlls/cabinet/cabinet.h 8 Jun 2005 14:05:42 -0000 > @@ -89,11 +89,17 @@ typedef UINT32 cab_off_t; > #define cffoldCOMPTYPE_QUANTUM (0x0002) > #define cffoldCOMPTYPE_LZX (0x0003) > #define cfheadPREV_CABINET (0x0001) > +#define cfhdrPREV_CABINET (0x0001) /* original name defined by MS */ > #define cfheadNEXT_CABINET (0x0002) > +#define cfhdrNEXT_CABINET (0x0002) /* original name defined by MS */ > #define cfheadRESERVE_PRESENT (0x0004) > +#define cfhdrRESERVE_PRESENT (0x0004) /* original name defined by MS */ > #define cffileCONTINUED_FROM_PREV (0xFFFD) > +#define ifoldCONTINUED_FROM_PREV (0xFFFD) /* original name defined by MS */ > #define cffileCONTINUED_TO_NEXT (0xFFFE) > +#define ifoldCONTINUED_TO_NEXT (0xFFFE) /* original name defined by MS */ > #define cffileCONTINUED_PREV_AND_NEXT (0xFFFF) > +#define ifoldCONTINUED_PREV_AND_NEXT (0xFFFF) /* original name defined by MS */ If these are the names defined by MS you should get rid of the others, there's no sense in having two different names for the same thing. > --- include/fci.h 28 Aug 2003 21:43:35 -0000 1.3 > +++ include/fci.h 8 Jun 2005 14:05:54 -0000 > @@ -112,15 +113,15 @@ typedef unsigned short TCOMP; > */ > > typedef enum { > - FCIERR_NONE, > - FCIERR_OPEN_SRC, > - FCIERR_READ_SRC, > - FCIERR_ALLOC_FAIL, > - FCIERR_TEMP_FILE, > - FCIERR_BAD_COMPR_TYPE, > - FCIERR_CAB_FILE, > - FCIERR_USER_ABORT, > - FCIERR_MCI_FAIL, > + FCIERROR_NONE, > + FCIERROR_OPEN_SRC, > + FCIERROR_READ_SRC, > + FCIERROR_ALLOC_FAIL, > + FCIERROR_TEMP_FILE, > + FCIERROR_BAD_COMPR_TYPE, > + FCIERROR_CAB_FILE, > + FCIERROR_USER_ABORT, > + FCIERROR_MCI_FAIL, The SDK header uses FCIERR, not FCIERROR. Why are you changing it? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Restructure WINE_WAVEOUT/WINE_WAVEIN
by Alexandre Julliard June 8, 2005

June 8, 2005

Jeremy White <jwhite(a)codeweavers.com> writes: > @@ -228,12 +205,20 @@ > > /* DirectSound stuff */ > DSDRIVERDESC ds_desc; > - DSCDRIVERCAPS ds_caps; > -} WINE_WAVEIN; > + DSDRIVERCAPS ds_caps; > + > + union { > + WINE_WAVEOUT out; > + WINE_WAVEIN in; > + }; You need to give a name to the union, anonymous unions are not portable. Though considering how few fields remain in the in/out structure you might just as well merge them into the common structure and use a single structure for everything. -- Alexandre Julliard julliard(a)winehq.org

1 0

Known regressions affectiong IE++ remain unfixed?
by René Rebe June 8, 2005

June 8, 2005

Hi all, I played a bit more with wine the last days and stumbled over this sidenet site which also has some FAQ points: http://sidenet.ddo.jp/winetips/config.html I experienced the same "IE installer crashing" with wine >= 200412xx - I wonder why such a long known regression takes so long to get fixed again. Currently the common way seems to be to install an over half a year old wine just to update it after the IE installation ... Aside from that, keep up your good work! Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45

1 0

Re: sysparams: Read the entire logfont from the registry if it's present
by Rein Klazes June 8, 2005

June 8, 2005

On Wed, 8 Jun 2005 12:32:27 +0100, you wrote: > > /*********************************************************************** > + * reg_get_logfont > + * > + * Tries to retrieve logfont info from the specified key and value > + */ > +static BOOL reg_get_logfont(LPCWSTR key, LPCWSTR value, LOGFONTW *lf) > +{ My guess is that this is not going to work for me. In my user.reg: | "MenuFont"=hex:0c,00,00,00,00,00,00,00,90,01,00,00,00,00,00,00,00,00,41,72,69,\ | 61,6c,00,40,65,9a,c2,ac,1c,00,01,00,00,00,00,01,00,00,00,6c,f8,56,00,01,00,\ | 00,00,8a,2d IOW it may be stored as a LOGFONT16 (as Win9x does) or a LOGFONTW and maybe a LOGFONTA somewhere as well. Rein..

1 0

Work being done at the File Creation Interface of Cabinet.DLL
by Gerold J. Wucherpfennig June 8, 2005

June 8, 2005

I just want to let you know that I'm working at the FCI functions of CABINET.DLL. I had a look at this a few years ago, but gave up soon. Two weeks ago I made a new attempt and next weekend I should be able I post a patch which implements all FCI functions and will work with spanning cabinets. Real file compression will not be implemented at that point of time as I still have to write missing parts and complete error handling first. This work took me longer than expected so let's see if I can adhere to my schedule. Regards, Gerold

2 2

config check for videodev.h
by Adrian Harvey June 8, 2005

June 8, 2005

I have been trying to test out the new webcam support with MSN, and have been having some trouble getting it to work. I have traced my problems back to an error in configure failing to compile the test for videodev.h, and therefore thinking that I have no v4l support. /usr/include/linux/videodev.h:55: error: syntax error before "ulong" /usr/include/linux/videodev.h:71: error: syntax error before '}' token The following patch fixes it for me, but I have little knowledge of autoconf, so I'm not sure if I've done the right thing? sys/time.h includes bits/types.h, and bits/types.h says it should not be included directly - and to use sys/types.h --- configure.ac.080605 2005-06-08 21:56:04.000000000 +1200 +++ configure.ac 2005-06-08 21:56:42.000000000 +1200 @@ -1226,6 +1226,7 @@ AC_CHECK_HEADERS(linux/videodev.h,,, [#ifdef HAVE_SYS_TIME_H #include <sys/time.h> +#include <sys/types.h> #endif #ifdef HAVE_ASM_TYPES_H #include <asm/types.h> The webcam support is truly amazing BTW - I never expected something like that to work so well in wine! Cheers, Adrian

2 1

wine-systray problem
by Pashok June 8, 2005

June 8, 2005

Hi all! i have trouble with wine-systray. I run windows program called "FCat". Wine-systray work correctly only under xfce-4.2.2. Under openbox-3.2 systray looks as small window on screen. Not in systray. Why? -- Sorry, im still using windows...

4 4

RE: setupapi - Danish and Swedish Translations
by Casper Hornstrup June 8, 2005

June 8, 2005

+COPYFILEDLGORD DIALOG LOADONCALL MOVEABLE DISCARDABLE 20, 20, 208, 105 +STYLE DS_MODALFRAME | DS_SETFONT | WS_POPUP | WS_VISIBLE | WS_CAPTION +CAPTION "Overførere Filer..." +FONT 8, "MS Shell Dlg" +BEGIN Should be: +CAPTION "Overfører Filer..." > -----Original Message----- > From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin(a)winehq.org] On Behalf Of Steven > Edwards > Sent: 8. juni 2005 00:33 > To: wine-patches(a)winehq.org > Subject: setupapi - Danish and Swedish Translations > > Changelog: > Danish translation by Thomas Larsen <sikker2004(a)yahoo.com> > Swdish translations by Anders Bergh <anders1(a)gmail.com> proofread by Andreas Bjerkeholt > <harteex(a)gmail.com> > > > > __________________________________ > Discover Yahoo! > Stay in touch with email, IM, photo sharing and more. Check it out! > http://discover.yahoo.com/stayintouch.html

1 0

Turning off the exception dialog
by Robert Lunnon June 8, 2005

June 8, 2005

The latest build of wine I am getting a dialog telling me about an exception rather than wine just dumping core. gdb can't catch the point of the exception allowing me to debug the problem. From memory there is a way to turn off this "feature" no ? Bob

1 0

[Resent]Request: Detect a broken pipe
by Uwe Bonnes June 8, 2005

June 8, 2005

Hallo, Alexandre just added my testcase to wine-patches, fingerpointing at a todo_wine() with wine not seeing a broken pipe. This still keeps Altera Quartus from starting up. I tried to fix for myself for some time , but to no avail. Any help/patches welcome. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Problems in bitblt (in x11drv)
by David Albrecht June 8, 2005

June 8, 2005

I'm new to wine and relatively new to windows programming being mostly a unix hack. Just for yucks I thought I'd get a relatively simple app emu48 to work. Turns out emu48 is not so simple (multi-threaded, etc.). First task towards functionality is to get the boot up display to look right and a BitBlt didn't seem to be functioning correctly. Much investigation later it turns out that in the file dib.c: /* if the source bitmap is 8bpp or less, we're supposed to use the * DC's palette for color conversion (not the DIB color table) */ is NOT true at least not for my case where the DC containing the bitmap has one palette and the colormap for the bitmap is not the same. If I disable the hPalette tests as I did below and always use the DIB colormap it boots up with the correct display otherwise the color mapping doesn't match the DIB bits and I get garbage. if (dib.dsBm.bmBitsPixel <= 8) { HPALETTE hPalette = GetCurrentObject( physDevSrc->hdc, OBJ_PAL ); if (/*!hPalette || (hPalette == GetStockObject(DEFAULT_PALETTE))*/1) { /* HACK: no palette has been set in the source DC, * use the DIB colormap instead - this is necessary in some * cases since we need to do depth conversion in some places * where real Windows can just copy data straight over */ colorMap = physBitmap->colorMap; nColorMap = physBitmap->nColorMap; } else { colorMap = X11DRV_DIB_BuildColorMap( physDevSrc, (WORD)-1, dib.dsBm.bmBitsPixel, (BITMAPINFO*)&dib.dsBmih, &nColorMap ); if (colorMap) aColorMap = TRUE; } } Not knowing the full ramifications of this code I thought I'd pass this along so that someone more familiar with it can reassess it. The DC and bitmap are created thusly: #if defined GRAYSCALE #define NOCOLORS 8 #else #define NOCOLORS 2 #endif static struct { BITMAPINFOHEADER Lcd_bmih; RGBQUAD bmiColors[NOCOLORS]; } bmiLcd = { {0x28,0/*x*/,0/*y*/,1,8,BI_RGB,0,0,0,NOCOLORS,0} }; VOID CreateLcdBitmap(VOID) { // create LCD bitmap _ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4); bmiLcd.Lcd_bmih.biWidth = LCD_ROW * nLcdDoubled; bmiLcd.Lcd_bmih.biHeight = -64 * nLcdDoubled; _ASSERT(hLcdDC == NULL); hLcdDC = CreateCompatibleDC(hWindowDC); _ASSERT(hLcdDC != NULL); hLcdBitmap = CreateDIBSection(hLcdDC, (BITMAPINFO*)&bmiLcd,DIB_RGB_COLORS, (LPVOID*)&pbyLcd, NULL, 0); _ASSERT(hLcdBitmap != NULL); hOldLcdBitmap = SelectObject(hLcdDC, hLcdBitmap); _ASSERT(hPalette != NULL); SelectPalette(hLcdDC, hPalette, FALSE); // set palette for LCD DC RealizePalette(hLcdDC); // realize palette BuildPattern(); // build Nibble -> DIB mask pattern UpdateContrast(Chipset.contrast); return; } Note that update contrast doe a SetDIBColorTable: VOID UpdateContrast(BYTE byContrast) { #if defined GRAYSCALE INT i; RGBQUAD c = *(RGBQUAD*)&dwKMLColor[byContrast]; // pixel on color RGBQUAD b = *(RGBQUAD*)&dwKMLColor[byContrast+32]; // pixel off color if ((Chipset.IORam[BITOFFSET] & DON) == 0 || I == *(DWORD*)&b) b = *(RGBQUAD*)&dwKMLColor[0]; // fill color palette of bitmap for (i = 0; i < ARRAYSIZEOF(bmiLcd.bmiColors); ++i) { const INT nCAdj[] = { 0, 1, 1, 2, 1, 2, 2, 3 }; _ASSERT(i < ARRAYSIZEOF(bmiLcd.bmiColors)); _ASSERT(i < ARRAYSIZEOF(nCAdj)); bmiLcd.bmiColors[i] = b; bmiLcd.bmiColors[i].rgbRed += (((INT) c.rgbRed - (INT) b.rgbRed) * nCAdj[i] / 3); bmiLcd.bmiColors[i].rgbGreen += (((INT) c.rgbGreen - (INT) b.rgbGreen) * nCAdj[i] / 3); bmiLcd.bmiColors[i].rgbBlue += (((INT) c.rgbBlue - (INT) b.rgbBlue) * nCAdj[i] / 3); } #else bmiLcd.bmiColors[1] = *(RGBQUAD*)&dwKMLColor[byContrast]; // pixel on color bmiLcd.bmiColors[0] = *(RGBQUAD*)&dwKMLColor[byContrast+32]; // pixel off color if ((Chipset.IORam[BITOFFSET] & DON) == 0 || I == *(DWORD*)&bmiLcd.bmiColors[0]) bmiLcd.bmiColors[0] = *(RGBQUAD*)&dwKMLColor[0]; #endif // update palette information _ASSERT(hLcdDC); SetDIBColorTable(hLcdDC,0,ARRAYSIZEOF(bmiLcd.bmiColors),bmiLcd.bmiColors); return; } The BitBlt: BitBlt(hWindowDC, nLcdX, nLcdY, 131*nLcdDoubled, nLines*nLcdDoubled, hLcdDC, Chipset.boffset*nLcdDoubled, 0, SRCCOPY); As emu48 still doesn't work I'll probably have more things I find in likely much different areas later. Dave

1 0

CPU Emulation
by Robert Lunnon June 7, 2005

June 7, 2005

Has any consideration been given to hooking a CPU emulation into wine to allow non x86 derivative CPUs execute native Windows binaries. For example it aught to be possible to hook qmu into the wine loader. Would this make a good Google Summer of Code project ? Wine could become Wine Is Now an Emulator Bob

4 3

Re: Fix our waveout tests by adjusting for underrun conditions
by Duane Clark June 7, 2005

June 7, 2005

Jeremy White wrote: > On my VIA8237 sound card at work, the Wave tests for winmm > have been failing for me with Alsa. > > > Now, this patch Works For Me (TM), on both of my systems, > but turning off the xrun mode seems like a big step to me; > I'd appreciate testing by any concerned parties. This seems to cause severe problems for VirtualDub: http://virtualdub.sourceforge.net/ Here is the movie I am using: http://ftp.pub.cri74.org/pub/win9x/video/SampleMovie/ If you open and run the movie, it plays ok, including sound. But try clicking stop in the middle of playing. Or when the movie gets to the end, everything is stuck; it appears the program cannot tell that the movie has ended. This is on current CVS, with winealsa (I think, at least that is what is set in my config file), and RH9.

1 0

Re: wine-systray problem
by Andreas Mohr June 7, 2005

June 7, 2005

[Darn, forgot group reply] Hi, On Tue, Jun 07, 2005 at 10:15:02PM +0600, Pashok wrote: > Andreas Mohr wrote: > > > >Maybe openbox-3.2 doesn't (fully?) support systray desktop guidelines > >(see freedesktop.org?) and thus Wine falls back to using a popup window > >instead? > > Maybe, but Openbox "was written first to comply with standards and to > work properly".... Hmm, then it should have worked if that fully was the case. > So i can't change this? I must use xfce??? I like openbox.... :( You are using Linux. You can change *EVERYTHING*. > -- > Sorry, im still using windows... Oh wait, you aren't... ;) If systray integration doesn't work despite openbox advertising standards compliance, then use some relevant Wine debug channel (it's probably dlls/shell32/systray.c, so it's WINEDEBUG=+shell) to find out what it tries to do and what doesn't work there. Andreas Mohr

1 0