- Wine-devel - list.winehq.org

Resent: WM_WINHELP, was: Re: Handling of messages above WM_USER...
by Uwe Bonnes 06 May '02

06 May '02

Hallo, appended message sent April 12 got no feedback so long. Perhaps anybody has an idea now... (Perhaps another example where native user might help ) >>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> I don't know if this global approach is valid, but at least it helped >> me to get winhlp32 working called with WinHelpA from an >> application. In what other way can we cope with user defined messages >> and their related structures in inter-process SendMessage? Alexandre> We can't. User messages cannot pass data around, WinHelpA Alexandre> will need to do that differently. The best way to find out Alexandre> how is probably to watch winhlp32 with a message spy under Alexandre> Windows. On Win95 OSR2 with Spy++ I could only see the Winhelp Message, nothing else special. Searching the web, I could find several approaches. However I think none of the required infrastructure is completly in place with wine yet - Allocate Remote memory The sending process allocates memory in the remote process with VirtualAlloxEx and copies the the local structure to that remote memory with WriteProcessMemory. Then the local process sends the WM_WINHELP message with the remote handle. This seems cleanest to me, but VirtualAllocEx is not yet implemented for remote processed. - Usage of shared memory (probably only on Win9X). Do we yet have shared memory? As we go the NT-way, this is probably depreciated. - Usage of SHAllocEx Probably requires support in the remote application to lock the passed handle, which is not the case for winhlp32.exe I could also see the possibility to inform the message-packer about the need to pack the WinHelp structure when RegisterWindowMessage is called. What other possibilities do other people see? Help and ideas appreciated. Bye -- 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

Comparison info please?
by Lonnie Cumberland 06 May '02

06 May '02

Hello All, I hope that all of you are doing well today. Recently, I have been doing some searching on the web and have come across different verions of Wine and am not sure how they compare to each other as far as advancements. I have found Wine (here), Rewind, and also WineX. could someone please tell me about the differences and also which might be the most advanced and stable? thanks in advance, Lonnie

4 5

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