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

Re: focused code review

by Bill Medland

On May 27, 2004 10:25 pm, Glen Kaukola wrote: > Hi, > > So one project suggested on the website is to do a focused code review. > In particular it talks about getting rid of inefficient uses of > strcat. But that leaves me wondering what exactly constitutes an > inefficient use of strcat? If anyone could provide an example I'd > appreciate it. Thanks. > > Glen (Not that I get particularly worked up about it; I find using strcat to be more readable) If you know the length of the string onto which you are adding the second string then you can simply strcpy; it saves the code remeasuring the string. e.g. (really lame example) void foo (const char *s1, const char *s2, char *buf, size_t len_buf) { int len_s1 = strlen(s1); int len_s2 = strlen(s2); if (len_s1 + len_s2 < len_buf && buf) { strcpy (buf, s1); strcpy (buf+len_s1, s2); } } -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

May 28, 2004

Re: Default to 96dpi for the no config file case

by Rolf Kalbermatter

>If you mean via DDC then I guess this should work in most places, but for >whatever reason it does not work here :( In particular, xdpyinfo says: > >screen #0: > dimensions: 1024x768 pixels (321x241 millimeters) > resolution: 81x81 dots per inch > >So it appears to know the screen size (I measured with a ruler and >321x241 is right), but it gets the DPI too small anyway. At 81 dpi the >text is hardly readable. But: 1024/321*25.4 = 81.026 768/241*25.4 = 80.943 Seems to me X has it very right. That Windows usually doesn't care about real resolutions and instead fudges with it (consider the Large Font setting in the Display Control Panel) is probably another issue. Or the metrics this function requires are not dots per inch but something else. Rolf Kalbermatter

May 28, 2004

Re: [Fwd: winetest: copy and submit manually]

by Dimitrie O. Paun

On Fri, May 28, 2004 at 07:42:54AM -0400, Robert Reif wrote: > It appears that the locale.c test on line 1866 and 1867 fail a lot > (0xffff?). Can you try to see why this happens on your box? > File too big (# > 1 MB), copy and submit manually > > where # is around 8 meg. Yeah, there's no point in submitting such a large file, it will be rejected by the server. The message about submitting manually is confusing, it should be 'this is a problem, please report (and investigate, if at all possible :))' -- Dimi.

May 28, 2004

Re: Default to 96dpi for the no config file case

by Rein Klazes

On Fri, 28 May 2004 13:59:02 +0100, you wrote: > If you mean via DDC then I guess this should work in most places, Yes, I can find the size here back in the /var/log/XFree86.log, similar to what xdpyinfo reports. > but for > whatever reason it does not work here :( In particular, xdpyinfo says: > > screen #0: > dimensions: 1024x768 pixels (321x241 millimeters) > resolution: 81x81 dots per inch > > So it appears to know the screen size (I measured with a ruler and > 321x241 is right), but it gets the DPI too small anyway. At 81 dpi the > text is hardly readable. Sorry, I believe you that your font is too small too read, but dpi means nothing else then dots-per-inch. And you have: 1024 dots per 321/25.4=12.6 inches which is 81.0 dpi. Are you watching a font with a known size? Try selecting same font and size in eg gnome-terminal. The sizes should be the same. Rein. -- Rein Klazes rklazes(a)xs4all.nl

May 28, 2004

Re: Default to 96dpi for the no config file case

by Dimitrie O. Paun

On Fri, May 28, 2004 at 01:59:02PM +0100, Mike Hearn wrote: > screen #0: > dimensions: 1024x768 pixels (321x241 millimeters) > resolution: 81x81 dots per inch > > So it appears to know the screen size (I measured with a ruler and > 321x241 is right), but it gets the DPI too small anyway. At 81 dpi the > text is hardly readable. No, this is quite good. If you want to be exact, it's 81.028x80.943 dots per inch, so 81x81 is pretty good. > Yep, this only affects the default when nothing is specified in the config > file (in fact in the default config file this was always specified anyway > so this is just restoring the old behaviour in the absence of he config > file really). Well, I don't think we should have this in the config file normally. That is, this value is (correctly) determined automatically. If it's not, it has to be corrected for X anyway, so we should just use what X gives us. However, Windows may adjust the real DPI, so we may have to apply a correction factor. I'd personally nuke this Wine-specific option altogether. -- Dimi.

May 28, 2004

Re: Default to 96dpi for the no config file case

by Huw D M Davies

On Fri, May 28, 2004 at 01:59:02PM +0100, Mike Hearn wrote: > On Fri, 28 May 2004 11:11:32 +0200, Rein Klazes wrote: > > Why do you mean (wrong) ? Do you not get the dpi values used by X? Or is > > it that is uses the X values but those are wrong? > > Well, I talked a bit with Huw about this so apologies to him if I mangled > what he said, but ... it seems that the functions we use to get the size > of the screen don't always return correct values. I don't know why. > > > Here X gets it from the monitor at start-up (via the logic of the video > > card). I did not realize that my situation is not normal. > > If you mean via DDC then I guess this should work in most places, but for > whatever reason it does not work here :( In particular, xdpyinfo says: > > screen #0: > dimensions: 1024x768 pixels (321x241 millimeters) > resolution: 81x81 dots per inch > > So it appears to know the screen size (I measured with a ruler and > 321x241 is right), but it gets the DPI too small anyway. At 81 dpi the > text is hardly readable. Well actually 1024 pixels in 321mm is about 81dpi, so the XServer is doing the sums correctly. I guess what we need to know is what resolution Windows returns on this same machine. Huw. -- Huw Davies huw(a)codeweavers.com

May 28, 2004

Re: Add documentation on the address space layout in Wine

by Mike Hearn

On Fri, 28 May 2004 09:10:22 +0200, Pouech Eric DMI AEI CAEN wrote: > Hi Mike > I've started to revisit the architecture.sgml file, and started to write > also about this matters (and a few others). For coherency reasons, if > you don't mind, I'll reintegrate your bits in the architecture.sgml file > (what you wrote covers also process image loading...). Sure, go ahead and do what you want with it. Do you know when you'll have something to submit? Also what else have you written about? I'm keen on getting as much of this low level technical detail down in writing so developers new to Wine stand a chance of understanding the scarier bits of the code. I was thinking of tackling DCOM next. thanks -mike

May 28, 2004

Re: Default to 96dpi for the no config file case

by Mike Hearn

On Fri, 28 May 2004 11:11:32 +0200, Rein Klazes wrote: > Why do you mean (wrong) ? Do you not get the dpi values used by X? Or is > it that is uses the X values but those are wrong? Well, I talked a bit with Huw about this so apologies to him if I mangled what he said, but ... it seems that the functions we use to get the size of the screen don't always return correct values. I don't know why. > Here X gets it from the monitor at start-up (via the logic of the video > card). I did not realize that my situation is not normal. If you mean via DDC then I guess this should work in most places, but for whatever reason it does not work here :( In particular, xdpyinfo says: screen #0: dimensions: 1024x768 pixels (321x241 millimeters) resolution: 81x81 dots per inch So it appears to know the screen size (I measured with a ruler and 321x241 is right), but it gets the DPI too small anyway. At 81 dpi the text is hardly readable. > I agree with you that 95 dpi is about the minimum that is being used > today. But I would keep this the minimum: if the dpi is set bigger then > it is probably intentional. Either monitor magic or from a careful > system administration. Yep, this only affects the default when nothing is specified in the config file (in fact in the default config file this was always specified anyway so this is just restoring the old behaviour in the absence of he config file really). thanks -mike

May 28, 2004

Re: Default to 96dpi for the no config file case

by Rein Klazes

On Thu, 27 May 2004 22:18:20 +0100, you wrote: > wineprefixcreate doesn't create a config file. This means we use a (wrong) > formula to decide what the DPI is supposed to be. Why do you mean (wrong) ? Do you not get the dpi values used by X? Or is it that is uses the X values but those are wrong? > It's wrong because > nobody tells the system how big their monitor is these days so it always > picks a DPI that is too small. Here X gets it from the monitor at start-up (via the logic of the video card). I did not realize that my situation is not normal. Somehow, I think setting a proper dpi should ideally be done in X. But in practice ... I agree with you that 95 dpi is about the minimum that is being used today. But I would keep this the minimum: if the dpi is set bigger then it is probably intentional. Either monitor magic or from a careful system administration. Rein. -- Rein Klazes rklazes(a)xs4all.nl

May 28, 2004

Re: Add documentation on the address space layout in Wine

by Pouech Eric DMI AEI CAEN

Hi Mike I've started to revisit the architecture.sgml file, and started to write also about this matters (and a few others). For coherency reasons, if you don't mind, I'll reintegrate your bits in the architecture.sgml file (what you wrote covers also process image loading...). A+ > Message du 28/05/04 01:35 > De : "Mike Hearn" > A : wine-patches(a)winehq.com > Copie à : > Objet : Add documentation on the address space layout in Wine > Mike Hearn > Add documentation on the address space layout in Wine > > Generated from: > * mike(a)navi.cx--2004/wine--mainline--0.9--patch-25 > > --- /dev/null 2003-09-15 14:40:47.000000000 +0100 > +++ documentation/address-space.sgml 2004-05-28 00:26:06.000000000 +0100 > @@ -0,0 +1,175 @@ > + > + > + > + > + Every Win32 process in Wine has its own dedicated native process on the host system, and > + therefore its own address space. This section explores the layout of the Windows address space > + and how it is emulated. > + > + > + > + Firstly, a quick recap of how virtual memory works. Physical memory in RAM chips is split > + into frames, and the memory that each process sees is split > + into pages. Each process has its own 4 gigabytes of address space (4gig > + being the maximum space addressable with a 32 bit pointer). Pages can be mapped or unmapped: > + attempts to access an unmapped page cause an EXCEPTION_ACCESS_VIOLATION which has the > + easily recognizable code of 0xC0000005. Any page can be mapped to any frame, therefore you can > + have multiple addresses which actually "contain" the same memory. Pages can also be mapped to > + things like files or swap space, in which case accessing that page will cause a disk access to > + read the contents into a free frame. > + > + > + > + > + > + > + When a Win32 process starts, it does not have a clear address space to use as it pleases. Many pages > + are already mapped by the operating system. In particular, the EXE file itself and any DLLs it > + needs are mapped into memory, and space has been reserved for the stack and a couple of heaps > + (zones used to allocate memory to the app from). Some of these things need to be at a fixed > + address, and others can be placed anywhere. > + > + > + > + The EXE file itself is almost always mapped at address 0x400000 and up: indeed, most EXEs have > + their relocation records stripped which means they must be loaded at their base address and > + cannot be loaded at any other address. > + > + > + > + DLLs are internally much the same as EXE files but they have relocation records, which means > + that they can be mapped at any address in the address space. Remember we are not dealing with > + physical memory here, but rather virtual memory which is different for each > + process. Therefore OLEAUT32.DLL may be loaded at one address in one process, and a totally > + different one in another. Ensuring all the functions loaded into memory can find each other > + is the job of the Windows dynamic linker, which is a part of NTDLL. > + > + > + > + So, we have the EXE and its DLLs mapped into memory. Two other very important regions also > + exist: the stack and the process heap. The process heap is simply the equivalent of the libc > + malloc arena on UNIX: it's a region of memory managed by the OS which malloc/HeapAlloc > + partitions and hands out to the application. Windows applications can create several heaps but > + the process heap always exists. It's created as part of process initialization in > + dlls/ntdll/thread.c:thread_init(). > + > + > + > + There is another heap created as part of process startup, the so-called shared or system > + heap. This is an undocumented service that exists only on Windows 9x: it is implemented in > + Wine so native win9x DLLs can be used. The shared heap is unusual in that anything allocated > + from it will be visible in every other process. This heap is always created at the > + SYSTEM_HEAP_BASE address or 0x65430000 and defaults to a megabyte in size. > + > + > + > + So far we've assumed the entire 4 gigs of address space is available for the application. In > + fact that's not so: only the lower 2 gigs are available, the upper 2 gigs are on Windows NT > + used by the operating system and hold the kernel (from 0x80000000). Why is the kernel mapped > + into every address space? Mostly for performance: while it's possible to give the kernel its > + own address space too - this is what Ingo Molnars 4G/4G VM split patch does for Linux - it > + requires that every system call into the kernel switches address space. As that is a fairly > + expensive operation (requires flushing the translation lookaside buffers etc) and syscalls are > + made frequently it's best avoided by keeping the kernel mapped at a constant position in every > + processes address space. > + > + > + > + On Windows 9x, in fact only the upper gigabyte (0xC0000000 and up) is used by the kernel, the > + region from 2 to 3 gigs is a shared area used for loading system DLLs and for file > + mappings. The bottom 2 gigs on both NT and 9x are available for the programs memory allocation > + and stack. > + > + > + > + There are a few other magic locations. The bottom 64k of memory is deliberately left unmapped > + to catch null pointer dereferences. The region from 64k to 4mb are reserved for DOS > + compatibility and contain various DOS data structures. Finally, the address space also > + contains mappings for the Wine binary itself, any native libaries Wine is using, the glibc > + malloc arena and so on. > + > + > + > + > + > + > + > + > + Up until about the start of 2004, the Linux address space very much resembled the Windows 9x > + layout: the kernel sat in the top gigabyte, the bottom pages were unmapped to catch null > + pointer dereferences, and the rest was free. The kernels mmap algorithm was predictable: it > + would start by mapping files at low addresses and work up from there. > + > + > + > + The development of a series of new low level patches violated many of these assumptions, and > + resulted in Wine needing to force the Win32 address space layout upon the system. This > + section looks at why and how this is done. > + > + > + > + The exec-shield patch increases security by randomizing the kernels mmap algorithms. Rather > + than consistently choosing the same addresses given the same sequence of requests, the kernel > + will now choose randomized addresses. Because the Linux dynamic linker (ld-linux.so.2) loads > + DSOs into memory by using mmap, this means that DSOs are no longer loaded at predictable > + addresses, so making it harder to attack software by using buffer overflows. It also attempts > + to relocate certain binaries into a special low area of memory known as the ASCII armor so > + making it harder to jump into them when using string based attacks. > + > + > + > + Prelink is a technology that enhances startup times by precalculating ELF global offset > + tables then saving the results inside the native binaries themselves. By grid fitting each > + DSO into the address space, the dynamic linker does not have to perform as many relocations > + so allowing applications that heavily rely on dynamic linkage to be loaded into memory much > + quicker. Complex C++ applications such as Mozilla, OpenOffice and KDE can especially benefit > + from this technique. > + > + > + > + The 4G VM split patch was developed by Ingo Molnar. It gives the Linux kernel its own address > + space, thereby allowing processes to access the maximum addressable amount of memory on a > + 32-bit machine: 4 gigabytes. It allows people with lots of RAM to fully utilise that in any > + given process at the cost of performance: as mentioned previously the reason behind giving > + the kernel a part of each processes address space was to avoid the overhead of switching on > + each syscall. > + > + > + > + Each of these changes alter the address space in a way incompatible with Windows. Prelink and > + exec-shield mean that the libraries Wine uses can be placed at any point in the address > + space: typically this meant that a library was sitting in the region that the EXE you wanted > + to run had to be loaded (remember that unlike DLLs, EXE files cannot be moved around in > + memory). The 4G VM split means that programs could receive pointers to the top gigabyte of > + address space which some are not prepared for (they may store extra information in the high > + bits of a pointer, for instance). In particular, in combination with exec-shield this one is > + especially deadly as it's possible the process heap could be allocated beyond > + ADDRESS_SPACE_LIMIT which causes Wine initialization to fail. > + > + > + > + The solution to these problems is for Wine to reserve particular parts of the address space > + so that areas that we don't want the system to use will be avoided. We later on > + (re/de)allocate those areas as needed. One problem is that some of these mappings are put in > + place automatically by the dynamic linker: for instance any libraries that Wine > + is linked to (like libc, libwine, libpthread etc) will be mapped into memory before Wine even > + gets control. In order to solve that, Wine overrides the default ELF initialization sequence > + at a low level and reserves the needed areas by using direct syscalls into the kernel (ie > + without linking against any other code to do it) before restarting the standard > + initialization and letting the dynamic linker continue. This is referred to as the > + preloader and is found in ld-winepreload.so (loader/preloader.c) > + > + > + > + Once the usual ELF boot sequence has been completed, some native libraries may well have been > + mapped above the 3gig limit: however, this doesn't matter as 3G is a Windows limit, not a > + Linux limit. We still have to prevent the system from allocating anything else above there > + (like the heap or other DLLs) though so Wine performs a binary search over the upper gig of > + address space in order to iteratively fill in the holes with MAP_NORESERVE mappings so the > + address space is allocated but the memory to actually back it is not. This code can be found > + in libs/wine/mmap.c:reserve_area. > + > + > + > + > + > --- documentation/wine-devel.sgml > +++ documentation/wine-devel.sgml > @@ -13,6 +13,7 @@ > > > > + > > > > @@ -138,6 +139,7 @@ > &implementation; > &porting; > &consoles; > + &address-space; > &cvs-regression; > > > > >

May 28, 2004