- Wine-Devel - list.winehq.org

Re: Support for running Winelib apps directly
by Boaz Harrosh Jan. 3, 2005

Jan. 3, 2005

Vincent Béron wrote: >Remove the loader script from Winelib apps. Winelib apps are still .so >files, but they can be launched directly now. > > > We did try to keep up with what wineapploader and wine did to load a fake-dll winelib app and all the spec.c magic that linked it all. Could you please elaborate a bit on what has changed and how it is all glued together? Is the embedded wineapploader Process reused for the main process for easier debugging? Currently when you debug a winelib app under GDB you cannot use wineapploader you need to use wine-kthread/pthread directly, and disable execshild and friends all together. Will that be at all possible now? Do you think it can be easier now for a: let's call it Unix app, to become a winelib application mid-flight. Lets say, when it wants to load a PE plug in DLL. (The way of mono and that Audio program can't recall the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC driver, therefor making the running app a winelib, Like PHP for example? If so could you make a little hello-world example of how it is done? Grate work Free Life Boaz

2 1

December 2004 - more patches than you can shake a stick at
by Mike Hearn Jan. 3, 2005

Jan. 3, 2005

Happy new year everybody! Being the patch fetishist that I am, I couldn't help noticing that in December 2004 we cleared 8mb of patches: that's by far the largest since the current archives began in October 2000. The extra traffic came from a lot of places: - Huge improvements to the Application Database. - The number was also pushed higher by an MSI merge from CodeWeavers. - Some big janitorial patches went in from Michael Stefaniuc - Finally Rob and I were cranking out DCOM patches, and there are of course lots more in the pipeline. Now time for some crystal ball gazing. Here are some interesting patches we might be seeing in 2005: - Completion of the WM rewrite work. Alexandre seems to be making great progress on this, which will let us fix many of the odd visual corruption problems we've been plagued with for so long. It'll also let us remerge Alexs winedesktop patch, giving us a real desktop window that is used for all apps, at last. It should have many other benefits too: fixing the flickering in the Half Life menus and allowing us to support the NETWM fullscreen protocol. This should let us resolve many instances of the "my game starts but I can't type" problem. - Lots more DCOM code. Huw Davies is hacking on getting widl to produce a stdole32.tlb file, once that's in we can start really nailing InstallShield to the wall. We will hopefully get this and the thread-affinity patches in the next few months, which should mean for the first time we can run InstallShield 6 installers perfectly, out of the box. Support for newer InstallShields will come as time permits of course. - More MSI improvements! CodeWeavers are continuing to work on this so it should develop nicely even though the iTunes installer work has been completed. Office 2003 will also motivate this. It's being used by at least one commercial app porting project as well. - Support for running Winelib apps directly, so we can get rid of the .exe.so extensions/shell wrapper scripts, and produce "raw" ELF binaries. They'll still need the wine loader app to be present of course, but it should all be invisible and behind the scenes. Vincent Beron and I have been working on this in the last week or so, and we just need to finish it off and convince Alexandre the extra assembly is worth it! :) Who knows what the new year will bring? More apps working out of the box, that's for sure! Have fun! thanks -mike

4 5

Re: Support for running Winelib apps directly
by Boaz Harrosh Jan. 3, 2005

Jan. 3, 2005

Vincent Béron wrote: >Remove the loader script from Winelib apps. Winelib apps are still .so >files, but they can be launched directly now. > > > We did try to keep up with what wineapploader and wine did to load a fake-dll winelib app and all the spec.c magic that linked it all. Could you please elaborate a bit on what has changed and how it is all glued together? Is the embedded wineapploader Process reused for the main process for easier debugging? Currently when you debug a winelib app under GDB you cannot use wineapploader you need to use wine-kthread/pthread directly, and disable execshild and friends all together. Will that be at all possible now? Do you think it can be easier now for a: let's call it Unix app, to become a winelib application mid-flight. Lets say, when it wants to load a PE plug in DLL. (The way of mono and that Audio program can't recall the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC driver, therefor making the running app a winelib, Like PHP for example? If so could you make a little hello-world example of how it is done? Grate work Free Life Boaz

1 0

Approving of the WINEprobe initiative
by David Gümbel Jan. 2, 2005

Jan. 2, 2005

Hello everybody, - as my colleague Stefan Munz has already pointed out recently[1] on this list, Wirtschaftsförderung Region Stutgart GmbH (WRS) and us (ITOMIG) are launching an initiative called WINEprobe[2]. Its goal is to make local software vendors aware of the potential bussiness opportunity in a WINE-based port or a WINE/Linux version of their software. WRS is quite committed as far as Open Source is concerned[3], and is pushing OSS in the region since quite a time. It has co-organized, among others, the KDE World Summit 2004 in Ludwigsburg near Stuttgart[4]. The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) [5], ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. (You can find a description of WRS at the bottom of this mail.) In order to make the WINEprobe initiative beneficial for the WINE project as much as possible, three things are in the making: 1) At the option of the respective software vendor whose product we'll be analyzing for WINE compatibility, Application Database Entries will be maintained by us once a software product has been analyzed for its compatibility with WINE. 2) Reports of successful porting or migration projects will be given back to the community as success stories. My colleage is already working on merging some success stories supplied by third parties (see [6]). 3) WRS has offered to help out in hosting the WINE developers conference Wineconf in 2005 in the Stuttgart area[7]. Mr. Schmid from WRS has asked me (please see the mail below) to provide some information about this initiative to the WINE community. He thinks (and I agree ;) that it would help us a great deal in making the campaign a success if the WINE community somehow "officially" (as official as a community can be :) approved of this initiative. So my question, on behalf of Mr. Schmid, is simply if there are objections against us saying that this initiative is approved of by the WINE community? As an important sidenote, I permit myself to emphasize that all of our above mentioned efforts (1-3) to support the WINE project and its community are fully independent of the answer of this question. Most particularily, the hosting offer stands, and the commitment there won't be lowered if the WINEprobe is not approved of by the community. However, I feel that a successful WINEprobe will be a benefit for the WINE project as well. If there are any questions open, please feel free to ask. Cheers, David ---------- Forwarded Message ---------- Subject: AW: Update on WRS offer & Stuttgart University Date: Montag 20 Dezember 2004 14:46 From: "Hans-Ulrich Schmid" <hans-ulrich.schmid(a)region-stuttgart.de> To: David Gümbel <david.guembel(a)itomig.de> Dear Mr. Gümbel, as you know, ITOMIG and Stuttgart Region is planning to start a new initiative for small and medium software companies called "WINEprobe". "WINEprobe" will help these companies to learn more about the WINE-compatibility of their software products. It would be very helpful, if you can ask the WINE-community to support this new initiative officially. The hosting offer of the Stuttgart Region will not be affected by any way of the decision of the community in the point of supporting the "WINEprobe" or not. Can you please forward this mail to the community and tell them some more about the background of "WINEprobe" Best regards Hans-Ulrich Schmid Wirtschaftsförderung Region Stuttgart GmbH Stuttgart Region Economic Development Corporation FIR_st - Forum IT-Region Stuttgart Friedrichstr. 10 70174 Stuttgart www.first.region-stuttgart.de www.opensource.region-stuttgart.de www.competenzatlas.de www.region-stuttgart.de Tel ++49.711.22835 - 27 Tel mobil ++49.172.7310463 Fax ++49.711.22835 - 55 ------------------------------------------------------- ------------------------------------------------------- WRS description: The Stuttgart Region Economic Development Corporation (WRS) is - founded to provide services to industry and communities in the field of economic development - a subsidiary of the administrative body of the larger Stuttgart Region - provides marketing for the Stuttgart Region - assists in cluster management of specific industries - advises and assists companies during the search for available sites and buildings In the context of our initiative "Open Source Region Stuttgart" http://opensource.region-stuttgart.de the WRS supports conferences and meetings of Open Source projects of various aspects when held in the Stuttgart Region. For example the WRS is co-organizer of the KDE Community World Summit 2004 in Ludwigsburg near Stuttgart http://conference2004.kde.org/ . The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) http://2005.guadec.org/papers.html , ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. ------------------------------------------------------- [1] http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html [2] WINEprobe means be something like WINEtasting in english an maybe "degustation de WINE" in french. [3] See http://opensource.region-stuttgart.de/ (.de only, sorry) [4] http://conference2004.kde.org/ [5] http://2005.guadec.org/papers.html [6] http://www.mail-archive.com/wine-devel%40winehq.org/msg11630.html [7] http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html

8 14

`__ctype_b' .. `__ctype_toupper'
by Dietrich Teickner Jan. 2, 2005

Jan. 2, 2005

Hi, I have updated to suse 9.1. After them I have this error. Where must be this definitions ? Dietrich ../../libs/libwpp.a(y.tab.o)(.text+0x2827): In function `combine_mtext': /home/sao2l02/Wine/wine/libs/wpp/./ppy.y:626: undefined reference to `__ctype_b' ... ../../libs/libwpp.a(lex.yy.o)(.text+0x3051):/home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1078: undefined reference to `__ctype_b' ../../libs/libwpp.a(lex.yy.o)(.text+0x3bfe): In function `is_c_h_include': /home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1411: undefined reference to `__ctype_toupper' collect2: ld returned 1 exit status make[2]: *** [widl] Fehler 1 make[1]: *** [widl] Fehler 2 make: *** [tools] Fehler 2

3 2

Re: oleaut.c small change to former patch an some more
by Marcus Meissner Jan. 2, 2005

Jan. 2, 2005

On Sat, Jan 01, 2005 at 04:25:34PM +0100, Dietrich Teickner wrote: > Hi Alexandre, > > I have some problems with SysReAllocStringLen in Odin(wine for os/2) and > the win32 MySqlQueryBrowser.exe. And I thing wine will have some times > the same. I thing we can / need no memcpy, if str and old the same > before realloc. We can reset the source (str) to NULL in this case. This > should solve the problem for wine and odin. While we do not really need memcpy here, I think we should understand the real problem you see. Is there any problem? What exactly is not working? (explaining what you do in Mysqlquerybrowser is ok, I have it running here.) Your patch would not handle a potential truncation if the "len" parameter is changed, right? Can you provide a testcase snippet for dlls/oleaut32/tests/vartype.c::test_SysReAllocStringLen() that shows different behaviour between real Windows and WINE? Ciao, Marcus

1 0

loading native binaries
by Ivan Leo Puoti Jan. 1, 2005

Jan. 1, 2005

Alexandre, your patch doesn't perform relocation, and this causes and access violation in secdrv.sys To perform relocation, we need to be able to write to memory, but there appears to be some sort of problem with this that causes wine to hang. I'm attaching your original patch, plus an updated one that Laurent Pinchar and I have come up with, it should work *in theory*, but it doesn't. Laurent has suggested that maybe it would if the image was aligned to a page boundary, but I'm to tired to look into it now. I'm cc'ing wine-devel, ideas/patches welcome. Ivan.

1 0

Re: Remove heap.h
by Jon Griffiths Jan. 1, 2005

Jan. 1, 2005

Hi, >>+ docA.lpszDocName = WtoA( doc->lpszDocName ); >>+ docA.lpszOutput = WtoA( doc->lpszOutput ); >>+ docA.lpszDatatype = WtoA( doc->lpszDatatype; >> >Isn't there a missing parenthesis? There sure is, I must have deleted it while removing the cruft from the diff (since it compiles fine on my box at home :). I'll resubmit. (Dimitrie) >Because in 99.99% of cases you don't want to convert from W->A. >If all our functions are Unicode, a W->A conversion is a warning >sign, and for sure you wouldn't want to encourage people to do >so by making it any easier. winapi_check will allready tell us all cross-calls anyway, doesn't it? It may be years before all the a to w conversions are done and we are 100% internally unicode, why live with a non standard header that long? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Jumbo Mail - fireworks
by puoti＠inwind.it Jan. 1, 2005

Jan. 1, 2005

Ciao, questa è una Jumbo Mail, che puoti(a)inwind.it ti ha inviato per condividere con te * video.zip (119256515 byte) e questo messaggio: -------------------------------------------------------------------------------- Greetings and Happy New Year from the Sorrento Peninsular. I've just finished taking this film of the New Year firework celebrations still going on all around. I took this film from our terrace, I hope you enjoy it. The file is big, 113MBs, so I don't recommend downloading it if you don't have broadband. The download link will expire in 7 days. Happy New year to all, Ivan. -------------------------------------------------------------------------------- Per scaricare questi files fai click sul seguente link: http://webmail.inwind.it/r.php?d=inwind.it&wr=_unreg_4eh3943v&ws=3850nl9t&e… Ti ricordiamo che questo link sarà valido fino al 08.01.2005 alle 07:23. Jumbo Mail è il servizio di Libero Mail che permette di condividere file di grandi dimensioni fino a 1GB, senza problemi di superamento dei limiti delle caselle e-mail. Scopri come è semplice e veloce inviare una Jumbo Mail! Fai click su http://liberomail.libero.it/jumbomail.phtml Lo staff di Libero

1 0

Re: Remove heap.h
by Filip Navara Dec. 31, 2004

Dec. 31, 2004

Jon Griffiths wrote: >+ docA.lpszDocName = WtoA( doc->lpszDocName ); >+ docA.lpszOutput = WtoA( doc->lpszOutput ); >+ docA.lpszDatatype = WtoA( doc->lpszDatatype; > Isn't there a missing parenthesis?

1 0