May 2002 - Wine-Devel - list.winehq.org

Re: Stripping of whitespaces at the end of lines

by Vincent Béron

Alexandre Julliard a écrit : > > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > If Alexandre wants to do it locally, I support him (our mailboxes will > > appreciate). > > If you want me to do that please send me a script that I can run > across the tree to do the change. Please don't send patches for this > kind of things. > > -- > Alexandre Julliard > julliard(a)winehq.com Here it is. It only targets .c and .h files. The diff was ~4MB in size between before and after. The savings in a .tar.gz of the whole tree were modest, around 25KB. Now to find a good set of arguments to feed indent(1) so we all use the same coding style... Not! ;) Vincent #!/bin/sh FILELIST=`find . $ -name \*.c -o -name \*.h $ -print` EXTENSION=notrailingspaces for eachfile in ${FILELIST}; do sed -e "s/[[:space:]]\+$//g" ${eachfile} >${eachfile}.${EXTENSION} ; sed -e "s/;\+$/;/g" ${eachfile}.${EXTENSION} >${eachfile} ; rm ${eachfile}.${EXTENSION} ; done

May 30, 2002

Re: PATCH: ImageList_LoadImageW (comctl32)

by Tony Lambregts

Sander van Leeuwen wrote: >Changelog: >- Match behaviour of ImageList_LoadImageA wrt cx parameter (when set to zero) > >Author: Sander van Leeuwen/Odin (sandervl(a)xs4all.nl) > > >--- imagelist.c Wed May 29 17:31:28 2002 >+++ imagelist.co Wed May 29 17:32:38 2002 >@@ -1907,19 +1907,6 @@ > if (uType == IMAGE_BITMAP) { > BITMAP bmp; > GetObjectA (handle, sizeof(BITMAP), &bmp); >- >- /* To match windows behavior, if cx is set to zero and >- the flag DI_DEFAULTSIZE is specified, cx becomes the >- system metric value for icons. If the flag is not specified >- the function sets the size to the height of the bitmap */ >- if (cx == 0) >- { >- if (uFlags & DI_DEFAULTSIZE) >- cx = GetSystemMetrics (SM_CXICON); >- else >- cx = bmp.bmHeight; >- } >- > nImageCount = bmp.bmWidth / cx; > > himl = ImageList_Create (cx, bmp.bmHeight, ILC_MASK | ILC_COLOR, > > > > > > Seems to me that you got this patch backward. - should + Tony Lambregts

May 30, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Ove Kaaven

On Wed, 29 May 2002, Laurent Pinchart wrote: > SafeDisc implements GetProcAddress internally, and verifies that the returned > address lies between ImageBase and ImageBase + SizeOfImage. It fails if it > doesn't. A warning: if I remember right, once you pass this hurdle, you'll encounter a check so hideous and nasty that if you can solve it without running afoul of the DMCA *and* have it accepted into Wine, I'd just about pronounce you a grand-master top-class super-elite hacker. Good luck...

May 29, 2002

Re: SafeDisc-1 semi-cleaned note...

by Uwe Bonnes

>>>>> "Laurent" == Laurent Pinchart <laurent.pinchart(a)skynet.be> writes: >> > WinNT Explorer crashes with an access to 07ffe0000 too. >> >> Well, then we should debug that and implement whatever it needs. We >> are never going to have a 100% compatible user shared data anyway, so >> there's no point in implementing things unless we know they are >> needed. Laurent> You're right. I still like the idea of a fault handler, but I Laurent> agree with you :-) Laurent> Uwe, could you tell me which memory location is accessed Laurent> exactly (and if possible a short assembly context) ? If WinNT Laurent> Explorer reads the 32-bit word at 0x7ffe0000 (TickCout) my Laurent> SafeDisc patch should fix the problem. It was not 0x7ffe000, if I remember right. Will try on Friday. Wine over ADSL with a lot of packet losses isn't fun. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

May 29, 2002

DOS memory Question..... or How to increase base memory for DOS apps

by Christian Costa

Hi, Many DOS apps needs a lot of base memory even if EMS or XMS memory are used. The first 64K of memory being lock to catch null pointer, the DOS memory must start at 0x10000 as you can see in the code below (msdos/dosmem.c) : /*********************************************************************** * DOSMEM_InfoBlock * * Gets the DOS memory info block. */ static dosmem_info *DOSMEM_InfoBlock(void) { return (dosmem_info*)(DOSMEM_dosmem+0x10000); /* 64K */ } /*********************************************************************** * DOSMEM_InitMemory * * Initialises the DOS memory structures. */ static void DOSMEM_InitMemory(void) { /* Low 64Kb are reserved for DOS/BIOS so the useable area starts at * 1000:0000 and ends at 9FFF:FFEF. */ Changing this value to the end of the BIOS DATA area (0x500) does the job and things work as expected (at least for DOS apps). But I was told that this causes problems for others apps. Probably for Win16 ones that use DOS3CALL and not int21h via DPMI. If it's true, a solution could be to initialize DOS memory differently for pure DOS apps by modifying the DOSMEM_Init function. DOSMEM_Init is called at 3 different places : - process_attach in dlls/kernel/kernel_main.c - DOSVM_Init in dlls/winedos/dosvm.c - MZ_InitMemory in dlls/winedos.dosvm.c and acts differently the first and second calls. Since I don't know wine internals enough and the "flow of execution", I have no idea how to do it in a clean way that do not break everything. If someone can help me or give me hints? A+ Christian

May 29, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Alexandre Julliard

Laurent Pinchart <laurent.pinchart(a)skynet.be> writes: > SafeDisc implements GetProcAddress internally, and verifies that the returned > address lies between ImageBase and ImageBase + SizeOfImage. It fails if it > doesn't. In that case the easy way would be to take the highest address from the export table and use that. It would actually be a pretty good approximation. The correct way would be a linker script; this is relatively easy to make work on one platform, but a bit more painful to make work for all platforms. -- Alexandre Julliard julliard(a)winehq.com

May 29, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Laurent Pinchart

> > I then checked the assembly code generated by gcc, and found out that > > _end - pe_header is computed by reading 2 valus in the .got section and > > substracting them. > > > > Could anyone help me ? > > > > Should I try with a linker script ? > > Maybe you should tell us why you need a correct value in there, it may > be possible to find a simpler solution. SafeDisc implements GetProcAddress internally, and verifies that the returned address lies between ImageBase and ImageBase + SizeOfImage. It fails if it doesn't. I could use a big value (0x80000000) for SizeOfImage but I don't like that. Laurent Pinchart

May 29, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Alexandre Julliard

Laurent Pinchart <laurent.pinchart(a)skynet.be> writes: > I then checked the assembly code generated by gcc, and found out that _end - > pe_header is computed by reading 2 valus in the .got section and substracting > them. > > Could anyone help me ? > > Should I try with a linker script ? Maybe you should tell us why you need a correct value in there, it may be possible to find a simpler solution. -- Alexandre Julliard julliard(a)winehq.com

May 29, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > don't you mean extern char _end[] instead ? > there's nothing currently which ensures that pe_header is at the start > of the code (it relies on the fact it's the first on gcc/ld link option, > and that ld allocates slots for compilation units in the order they are > expressed) => this may become a porting issue > I'm not sure either that _end is completly portable? > > using this technique (with _start, _etext, _edata, _bss_start, _end) we > could also compute the "real" size of code, data, and bss which should > be of some interest (even if data would be a bit more difficult, since > we need to take care of the rsrc part) If you really want to get everything right you have to write a linker script. This also allows making the PE header the first thing in the image. It's not very portable but it's easy to have a linker script for each platform. I played a bit with that back when we were trying to make the Visual C++ debugger work on builtin dlls, I may be able to find this code somewhere if someone is interested. -- Alexandre Julliard julliard(a)winehq.com

May 29, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Laurent Pinchart

On Wednesday 29 May 2002 22:40, Eric Pouech wrote: > > I thought about modifying winebuild to add > > > > char _end[]; > > nt_headers->OptionalHeader.SizeOfImage = pe_header - _end; > > > > in the library initialisation function. This is small, fast and probably > > more accurate. > > > > Does anyone have any comment about that ? > > don't you mean extern char _end[] instead ? Yes, sorry. > there's nothing currently which ensures that pe_header is at the start > of the code (it relies on the fact it's the first on gcc/ld link option, > and that ld allocates slots for compilation units in the order they are > expressed) => this may become a porting issue > I'm not sure either that _end is completly portable? I don't know either. We could instead add a linker script which would set a symbol to the difference between the end and the start of the file. That should be more portable. > using this technique (with _start, _etext, _edata, _bss_start, _end) we > could also compute the "real" size of code, data, and bss which should > be of some interest (even if data would be a bit more difficult, since > we need to take care of the rsrc part) One thing at a time please :-) I tried the code described above, but it unfortunately doesn't work for all dlls. It returns a correct value in some cases (for small dlls it seems), and a huge negative value around 0xc0000000 in other cases (for bigger dlls). I check the pe_header and _end symbols using nm and they are correct everytime. I then checked the assembly code generated by gcc, and found out that _end - pe_header is computed by reading 2 valus in the .got section and substracting them. Could anyone help me ? Should I try with a linker script ? Laurent Pinchart

May 29, 2002