- Wine-Devel - list.winehq.org

Re: ntdll: Implement and test RtlAnsiCharToUnicodeChar
by Alexandre Julliard June 9, 2005

June 9, 2005

James Hawkins <truiken(a)gmail.com> writes: > +/************************************************************************** > + * RtlAnsiCharToUnicodeChar (NTDLL.@) > + * > + * Converts an ansi character to a unicode character. > + * > + * PARAMS > + * ansi [I/O] Pointer to the ansi string. > + * > + * RETURNS > + * Success: Unicode representation of the first character in the ansi string. > + * Failure: NULL. > + * > + * NOTES > + * Upon successful completion, the char pointer ansi points to is > + * incremented by one. It should be incremented by two for multi-byte characters. -- Alexandre Julliard julliard(a)winehq.org

1 0

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 8, 2005

June 8, 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 8, 2005

June 8, 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 8, 2005

June 8, 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 8, 2005

June 8, 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 8, 2005

June 8, 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