January 2006 - Wine-devel - list.winehq.org

RFC: pch support
by Steven Edwards 13 Jan '06

13 Jan '06

Hi, Alexandre did not like the needed changes required to add support for this but I figured I would throw it out for debate anyway in case anyone else can make him change his mind (duck). The issue is he does not like needing a single header per-program or per dll. After doing some research it seems to me that even MSVC does not support multiple PCH files per project so I don't know how it could be fixed in gcc to do it Microsoft has not figured it out. problem: ccache works great for speeding up compiles but seems to still have issue with some header changes. Also the ReactOS guys really want to add pch support to the Wine dlls that are shared so the job falls to me to sell it to Wine. Solution: Below are the benchmarks from my box and a patch. Simply patch your tree and then ./configure and cd to the regedit folder and do a 'time make','make clean','make pch', and 'time make' if you want to see the speedup on your box. I expect we could get a 2x speedup in fresh compiles of Wine with pch support Regedit compile without pch real 0m5.632s user 0m5.000s sys 0m0.524s Regedit compile with pch real 0m2.797s user 0m2.352s sys 0m0.428s -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 12

FAQ outdated in one point
by CS 13 Jan '06

13 Jan '06

In the FAQ you write under "2.12. When will Wine be finished?": "Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005." maybe that should be updated or removed altogether so there don't need to be updates to this entry in the future. sorry that I can't do more to contribute :-) clem

2 1

re: richedit's RTF writer writes only 8 kBi
by Dan Kegel 13 Jan '06

13 Jan '06

In June '05, Tobias Burnus complained in http://www.winehq.com/hypermail/wine-devel/2005/06/0536.html that there seemed to be an 8kB size limit on rich text output from richedit... but nobody replied to his message. Tobias, did you ever resolve that problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Regression in ntdll/virtual.c
by Markus G�mmel 13 Jan '06

13 Jan '06

I mentioned that the setup program of AstroWorld will not work any longer since a few days. Regression testing resulted in the change of ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry in wine.patches, so here is the diff result: 37a38 > #include <sys/stat.h> 837a839 > struct stat st; 859a862,866 > if (fstat( fd, &st ) == -1) > { > status = FILE_GetNtStatus(); > goto error; > } 860a868 > if (header_size > st.st_size) goto error; 999c1007,1009 < if (map_file_into_view( view, fd, sec->VirtualAddress, file_size, sec->PointerToRawData, --- > end = sec->PointerToRawData + file_size; > if (sec->PointerToRawData >= st.st_size || end > st.st_size || end < > sec->PointerToRawData || > map_file_into_view( view, fd, sec->VirtualAddress, file_size, > sec->PointerToRawData, The program can be downloaded for free at http://www.astroworld.de/ger/. Simply select "AW2001 v.6.2 (English)" in the first selection box and press "Download Demo". With the new version of aw61eng.exe it stuck somewhere at 22% with an error message like "~TMD61.tmp" is not a Win32 binary". With the old version the setup run ok. Thanks and regards Markus Gömmel m.goemmel(a)compulab.de

1 0

Re: winspool: updated some traces for bug 4268
by Huw D M Davies 13 Jan '06

13 Jan '06

On Fri, Jan 13, 2006 at 03:51:36PM +0100, Detlef Riekenberg wrote: > Changelog: > > - winspool: updated some traces for bug 4268 > > > -- > By By ... > ... Detlef > diff --git a/dlls/winspool/info.c b/dlls/winspool/info.c > index 9b1771d..a4caa39 100644 > --- a/dlls/winspool/info.c > +++ b/dlls/winspool/info.c > @@ -247,13 +247,16 @@ static BOOL CUPS_LoadPrinters(void) > HKEY hkeyPrinter, hkeyPrinters, hkey; > > cupshandle = wine_dlopen(SONAME_LIBCUPS, RTLD_NOW, NULL, 0); > + TRACE("%p: CUPS loaded (%s)\n", cupshandle, SONAME_LIBCUPS); > if (!cupshandle) > return FALSE; > - TRACE("loaded %s\n", SONAME_LIBCUPS); That's a very confusing TRACE. If wine_dlopen fails then why not print out something like "CUPS not loaded" ? > @@ -439,6 +442,8 @@ PRINTCAP_LoadPrinters(void) { > BOOL had_bash = FALSE; > > f = fopen("/etc/printcap","r"); > + TRACE("%p: using /etc/printcap\n", f); > + > if (!f) > return FALSE; > The same applies to this too. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Linuxtag 2006
by Uwe Bonnes 13 Jan '06

13 Jan '06

Hallo, has anybody interest in activly participating in a Wine booth in Linuxtag 2006 (http://www.linuxtag.org/2006/de/home/cfpro.html) in Wiesbaden from May 3 to May 6? Please let me know. Projects should have applied before Feb. 3. 2006. If needed, I can provide a place to sleep here in my flat in Darmstadt. 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

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSection on top of DoInfInstall > I'm afraid this implementation isn't correct. DoInfInstall calls SetupInstallFromInfSection which only concerns the Install section of an INF file. SetupInstallFromInfSection and consequently DoInfInstall cannot provide enough functionality for LaunchINFSection/Ex. LaunchINFSection/Ex also takes into acount reg and file saves (see Reg/FileSaveRestore), per user sections (see SetPerUserSecValues), registering ocx's, extracting cabinets, and a whole mush of other intricacies. LaunchINFSection/Ex basically combines all the other functions of advpack into a monstrosity of functionality. I'm working my way towards fully implementing LaunchINFSection/Ex, but I've got to finish the lower levels first, so if you'd like to help in this direction, take a look at the stubs I've mentioned in advpack. I appreciate your effort in this implementation, but it will do more harm than good because we'll have to take it out when it comes time to fully implement LaunchINFSection. -- James Hawkins

2 2

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by Markus Amsler 13 Jan '06

13 Jan '06

James, I just saw your advpack patches. Only patch 4 (* Add stubs for the file save/restore functions), Makefile.in gets a merge conflict with mine first 1 (Move inf install functions to install.c ). The rest applies fine (some offset warnings), and builds without warning. Should I rediff against yours or you against mine? Is there a better way to coordinate our efforts? My LaunchINFSectionEx patch seems to improve bug 3636. Markus

1 0

New wannabe developer
by Dan Kegel 13 Jan '06

13 Jan '06

Zoe wrote: > Hi, I've got nothing better to do at the moment so I was wondering what > the best way to help move things forwards and contribute back to the > project. :-) Glad to meet you :-) I have a page that might help: http://kegel.com/wine/sweng/ Hope it helps. Let me know if there's anything unclear there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: Alexandre Julliard : server: Don't round up the header size for image mappings.
by Michael Jung 13 Jan '06

13 Jan '06

Hi, On Wednesday 11 January 2006 21:34, Alexandre Julliard wrote: > http://source.winehq.org/git/?p=wine.git;a=commit;h=b54e9e94e98624acde1bb00 > e10c2055dfed9c2d7 > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Jan 11 20:59:26 2006 +0100 > > server: Don't round up the header size for image mappings. This patch prevents certain executables (at least those generated with Borland C++ 5.02) from being loaded. I've attached a small example. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0