wine-devel

wine-devel@winehq.org

4 participants
84403 discussions

Start a nNew thread

Docu: PE-Loader
by juergen.schmied＠debitel.net 06 May '02

06 May '02

Might be useful: http://www.smidgeonsoft.prohosting.com/#Windows%202000%20Loader Bye Juergen

1 0

RE: More MSVC fixes
by Patrik Stridvall 06 May '02

06 May '02

> > > However Alexandre doesn't like binary files in the CVS > for good reasons > > While I can see that to a point, it's not 100% clear to me > that storing a .gif > (or what have you) in CVS is such a bad idea. I mean, the > main advantage > of storing stuff as plain text is to be able to look at (and > undrestand :)) > the diffs. However, that's not the case for images, even when > stored in a > text format. > > CVS can handle binary files no problem. Can someone please refresh my > memory on why storing binary _images_ in CVS is such a bad idea? I think it is because CVS can't store the diffs between binary files. It stores the whole file even if only one byte change. So it takes a lot of space to store the history of the file. Of course storing space is cheap nowadays...

6 10

Whatever happend to winepath?
by Michael Wetherell 05 May '02

05 May '02

I posted a utility to convert between unix and DOS paths the other day, something like cygwin's cygpath, and it didn't get applied. So I was wondering why? Was it not thought to be useful or was there semething wrong that I can fix? MIke

2 1

Help with LCM_Unicode_LUT in ole2nls.c wanted
by Uwe Bonnes 05 May '02

05 May '02

Hallo, looking at LCMapStringW, I think we need some table like the LCM_Unicode_LUT[] table. However - I don't understand where the values come from. Odd values seem to be a collation of flags, even values to be some character weight and LCM_Diacritic_LUT[] is some weight for the diacritic. - Do the tables in ../wine/unicode somehow contain enough information to generate these tables? Help and pointers appreciated. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

3 3

Re: A dsound regression
by Duane Clark 05 May '02

05 May '02

Johan wrote: > On Fri, 3 May 2002, Duane Clark wrote: > >> A little more regression testing... >> >> The 5/1 dsound patch causes this on one of my apps: > ... >> err:wave:DSDB_MapPrimary (0x4568ca04): Could not map sound device for >> direct access (Input/output error) > > Before the patch Riven falls back to winmm, making the sound work. > > After the patch Riven can use DirectSound, but fails because your > soundcard and driver can't do mmap(). > Just for reference, this is a VIA 82C686 under ALSA 0.9beta12, which is probably a pretty common sound system. Also, I am a bit puzzled, since the map error comes after the LoadLibraryExA errors.

1 0

Re: GDI separation patch
by Dmitry Timoshkov 05 May '02

05 May '02

"Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> wrote: > + { /* free its selector array */ > + WORD sel = SELECTOROF(bmp->segptr_bits); > + WORD count = (GetSelectorLimit16(sel) + 1) + 0xffff / 0x10000; ^^^^^^^^^^^^^^^^^^ Something wrong here. > BTW, does anyone have an idea how to get rid of the remaining LOCAL_xxx() > calls in gdiobj.c ? GDI objects management should be moved eventually to wineserver. I can confirm Alexandre's suspicion about that undocumented behaviour. At least the following code works on windows2000: HWND hWnd; HBRUSH hBrush; LOGBRUSH lb; int nbytes; hWnd = FindWindow(NULL, "Calculator"); assert(hWnd); hBrush = (HBRUSH)GetClassLong(hWnd, GCL_HBRBACKGROUND); assert(hBrush); nbytes = GetObject(hBrush, sizeof(LOGBRUSH), &lb); assert(nbytes == sizeof(LOGBRUSH)); -- Dmitry.

1 0

Re: GDI separation patch
by Eric Pouech 05 May '02

05 May '02

> BTW, does anyone have an idea how to get rid of the remaining LOCAL_xxx() > calls in gdiobj.c ? > We need those because we do > GDI_HeapSel = instance | 7; > , so we directly use the GDI instance plus 7 as the heap selector > for GDI objects (thus we can't do a standard LocalInit, as this would > allocate a *new* selector for the new heap instead of using the implicit > GDI module one, and thus we need to pass the GDI_HeapSel to LOCAL_Alloc instead) I'd say: write a wrapper in gdi which 1/ sets DS to the GDI_HeapSel value 2/ calls LocalAlloc16 (for instance) (the call has to be a 16 bit call), so you need the relay to be generated for this 16 bit call 3/ restores old DS value (before 1) this sounds hacky, but it was a standard way of using the LocalXXX on several 64k buckets at the same time you may also create a new type of 32 => 16 relay stub, which sets DS to a passed value... (that'd be IMO the cleanest way...) A+

2 2

RE: More MSVC fixes
by Patrik Stridvall 05 May '02

05 May '02

> How are you planning on linking the dlls/resources once wine is up 2 > date on MSVC? No specific plan. I just fix issues that I can find acceptable solutions to one by one in hope that all will be fixed eventually. You and Alexandre have fixed some of them that I wasn't sure how to solve in an acceptable way so, as I said, perhaps we will solve them all eventually. :-) > Can MSVC build wrc resources and link them? The formats are not 100% compatible. Specificly WRC supports embedded icons and bitmaps. Microsoft RC requires a link to the binary. However Alexandre doesn't like binary files in the CVS for good reasons so making the RC files 100% Microsoft compatable wouldn't be a good idea either. Not sure how to solve this in a good way other than actually using WRC on Windows of course.

6 8

Issues building the spec.o on win32 with mingw
by Steven Edwards 04 May '02

04 May '02

I get this on almost every *.spec.o Administrator@LAPTOP /cygdrive/d/src/winehq/wine/dlls/commdlg $ make PATH="../../unicode:$PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../ include -o rsrc.res -r rsrc.rc PATH="../../unicode:$PATH" ../../tools/winebuild/winebuild -L../../dlls -o comm dlg.spec.c -spec commdlg.spec gcc -mno-cygwin -c -I. -I. -I../../include -I../../include -D__MINGW__ -D_WINDO WS -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o commdlg.spec.o commdlg.spec.c /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s: Assembler messages: /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s:1104: Warning: unknown se ction attribute 'a' /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s:1106: Error: unknown pseu do-op: `.previous' make: *** [commdlg.spec.o] Error 1 Any ideas? I really don't need the spec because I can do a -l if I can build the .a for ntdll and a few others. I can use dlltool with the *.defs and then I only need winebuild to make the *.defs. Only problem is winebuild wants so's not dll's when building a def or looking for imports. I was going to have a look at the loader/winedump code for ideas but I thought I would ask here first. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

4 8

A dsound regression
by Duane Clark 04 May '02

04 May '02

A little more regression testing... The 5/1 dsound patch causes this on one of my apps: err:module:BUILTIN32_LoadLibraryExA loaded .so but dll sound.dll still not found - library environment problem or version conflict, check your setup. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll sound.dll still not found - library environment problem or version conflict, check your setup. err:wave:DSDB_MapPrimary (0x4568ca04): Could not map sound device for direct access (Input/output error)

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel