- Wine-Devel - list.winehq.org

Fwd: WINE virus thing
by Dimitrie O. Paun Nov. 6, 2002

Nov. 6, 2002

---------- Forwarded Message ---------- Subject: WINE virus thing Date: Tue, 5 Nov 2002 22:33:29 +0100 (MET) From: Marcel Partap <mpartap(a)gmx.net> To: dpaun(a)rogers.com Dear Dimitrie, I am not on the mailing list for wine so please redirect this to the list, thank you very much. I've read the Wine weekly news and would like to help out a bit. About that security thingie and the problem that some apps need manual parameters or something (the user has to do more than click-click) I would recommend following solution: Most Nintendo 64 Emulators use INI-files, in which for each game (ROM Image) the name and shit is listed and the best options specifically for this game. I would recommend to do it exactly like this in WINE: a Application database file with weekly updates (like Antivirus definitions) which contains the names and file attributes of the (tested) application (MD5??!) and eventually the parameters necessary to run the program. Wine could then have a secure mode (turned on by default) in which only applications from the DB (MD5!) can be run and an unsecure mode in which it will run any EXE. This would solve multiple problems at once: -the parameters the program needs to work will be used automatically -no "click-click-infections" because virii not in app database -approach for bringing structure into that nasty online app database :) BTW if MD5 is in the app database aswell, each existing version of the app (that *works*) needs to be verified by someone and the MD5 added to the database. I don't think that'd be a great problem. hope you hear me cya Marcel -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ------------------------------------------------------- -- Dimi.

2 1

Lost Wages (round 2)
by Jeremy Newman Nov. 6, 2002

Nov. 6, 2002

I spent some time implementing my theme idea to the lostwages devel version of the WineHQ website. Take a look at: http://lostwages.winehq.org On the home page, use one of the three theme links. I've made the skinning engine pretty simple so more themes/skins could be added in the future. I also removed the hidden menus, and returned to the standard view like Francois has been evangelizing. Most of the links go 404 for the moment. But the About page is in as a sample. Next on my list is to work on using /about/ style URLs instead of page=About get style. Then I need to port WWN to use the new theme engine (its busticated in the lostwages version). That's all for now. -- __ _WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | / -_) | | / ' \/ _` | ' \ -= jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

6 10

Avoiding FunctionA/W Duplication
by Jaco Greeff Nov. 6, 2002

Nov. 6, 2002

I would like some comments on somthing that has been bugging me quite a bit. Implementing parts of the API can lead to duplication of code inside the same file. In my example, let's take two functions, one operating on a ASCII string and one one a Unicode string, let's call them "funcA" and "funcW". Upon implementation, the only real difference between these are the parameters, "funcA(const char *p)" and "funcW(const WCHAR *p)". What is the best way to keep the code maintainable and making sure that we don't have to fix a single bug in two places in the same file? I see 3 (maybe more) approaches: 1. Implement funcA, making funcW and exact copy with the relevant parameters and local variables changed; 2. Implement a generic solution as a macro and get both funcA and funcW to call it will specific parameters; 3. Do some preprosessor magic as implemented in dlls/msvcrt/scanf.[hc] What is the general feeling as to the right way to approach this? What is the preferred approach? (And maybe it is something I haven't listed here.) At this point, I've been following approach 1, which makes me a bit uncomfortable with regardsto code bloat and forever having to make sure that funcA is on par with funcW and vice versa. I've toyed with the idea of 2, but as Dimitrie rightly said, it is a bit C++-ish :) (Plus it doesn't do wonders for debugging...) Number 3, yes it works, but it can add extra files. (Altough it almost seems the best of the 3 I've listed.) Your comments would be appreciated, somewhere there is the best solution that will be agreeable to all and which makes sure things stay relatively simple. (Well, simplicity across two functions at least.) Greetings, Jaco

4 4

[Fwd: x11drv WND separation]
by David Fraser Nov. 6, 2002

Nov. 6, 2002

Hi Have had trouble getting through to wine-devel(a)winehq.com, so reposting this to see... Funny, nothing's bounced... David -------- Original Message -------- Subject: x11drv WND separation Date: Mon, 04 Nov 2002 15:27:27 +0200 From: David Fraser <davidf(a)sjsoft.com> To: dpaun(a)rogers.com, wine-devel(a)winehq.com CC: julliard(a)winehq.com References: <200210311738.10609.dpaun(a)rogers.com> <87k7jy5i0i.fsf(a)mail.wine.dyndns.org> <200210312356.30812.dpaun(a)rogers.com> Dimitrie O. Paun wrote: >On October 31, 2002 06:02 pm, Alexandre Julliard wrote: > > >>"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: >> >> >>>What is NOT in 0.8: >>> -- stable server protocol: no binary compatibility >>> -- DLL separation: ditto >>> >>> >>IMO the goals for 0.9 will be reached before the ones for 0.8 so you >>might as well put everything together... >> >> > >Maybe so, you know this better. But 0.9 needs what's listed >here anyhow, if we hit the 0.9 targets before, no harm's done. >I am not that optimistic about the DLL separation. The x11drv >is a bit of a mess, as we have a WND structure maintained by >USER, which x11drv needs access to. It needs work. And in >general, the separation work that's left is not trivial, >and you seem to be the only one qualified to do it. And you >are one busy guy... > > Does anyone have any info on what needs to be done to separate out the WND structure from USER? Is there any other stuff that should be separated out into x11drv? Presumably even if the separation isn't trivial some pointers could enable others to give it a try... David

3 2

Re: WineHQ menu (take 3)
by Igor Izyumin Nov. 6, 2002

Nov. 6, 2002

On Monday 04 November 2002 05:59 pm, you wrote: > On November 4, 2002 06:46 pm, Igor Izyumin wrote: > > Are you referring to Konqueror? Seem to work fine on my machine. KDE > > 3.0.3. > > Yes. I use RH 8.0 (KDE 3.0.3), but these menus _always_ failed to properly > render in Konqy. Check it out: > > http://24.103.156.204/bad-konqy.png OK, now I see what the problem is. Something is set in the HTML so that the text makes the table wider instead of wrapping. However, Konqueror apparently miscalculates font sizes. I can reproduce this on Mozilla if I turn on 200x font zoom, but then you can actually see the text pushing on the menu side. I can't see that in your screenshot. Anyway, this can probably be solved by tweaking the stylesheet. Jeremy Newman came up with a different design, so I doubt that the current one will get adopted. If it does, I'll try to find a solution. Unfortunately, HTML and even CSS are supported in a very inconsistent manner, so it's difficult to make something that works well on everything. -- -- Igor

5 6

OT: Wine history
by Chris Morgan Nov. 6, 2002

Nov. 6, 2002

Tom Wickline showed me a faq page he is working on and I came upon the history of wine that I've read before but have always been curious about. This is the faq entry: What's the history of Wine? The Wine project started in 1993 as a way to support running Windows 3.1 programs on Linux. Bob Amstadt was the original coordinator, but turned it over fairly early on to Alexandre Julliard, who has run it ever since. The newsgroup was created in July 1994. Over the years, ports for other Unixes have been added, along with support for Win32 as Win32 applications became popular. Also see http://www.winehq.com/about.shtml I was curious as to whether anyone knew where Bob Amstadt went and if there were some of the "old timers" that would be willing to tell some stories of the dawn of wine development. How people looked at the project, who was around early on, big development pushes, anything people might find interesting. ;-) Chris

1 0

Mozilla 1.0.1 Win32 works almost flawlessly
by Jakob Eriksson Nov. 6, 2002

Nov. 6, 2002

There you have it. Yes, it's exciting. :-) -------- Original Message -------- Subject: Re: win-mozilla on wine Date: Sun, 3 Nov 2002 12:56:14 -0500 From: "Dimitrie O. Paun" <dpaun(a)rogers.com> Reply-To: dpaun(a)rogers.com Organization: DSSD Software Inc. To: Jakob Eriksson <jakob(a)vmlinux.org> References: <3DC5616B.4090205(a)vmlinux.org> On November 3, 2002 12:48 pm, Jakob Eriksson wrote: > I just tried Mozilla 1.0.1 Win32 on Wine 20021031 > > Works mostly fine. Resizing works, I think it didn't a couple > of months ago. This is great news. You should report this on the list, so people know, and we can discuss there. If you don't mind, of course. > The meny "File Edit View Go " etc is gone however. > Strange? Yes, we should fix this. This is exciting, eh? :) -- Dimi.

3 2

COM error!!
by 朱剑民 Nov. 6, 2002

Nov. 6, 2002

COM error! I have test COM On wine. Tonight,I wrote a test program First,I called CoInitializeEx(NULL, COINIT_MULTITHREADED)... Second,I called CoGetClassObject(rclsid, dwClsContext, NULL,IID_IClassFactory, (PVOID*)&pcf) and return "RPC_S_INVALID_STRING_BINDING", It means The string binding is invalid. who can tell why?? Thanks kevin

1 0

Re: Avoiding FunctionA/W Duplication
by Jaco Greeff Nov. 6, 2002

Nov. 6, 2002

On 05 Nov 2002 13:42:15 -0500, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote : > From what I saw in a couple of places: from funcA, do some magic on the > parameters (convert to Unicode), then call funcW, then reconvert the > result from Unicode to ASCII. Yes you have to convert twice, but you use > the same function. I'm happy with that and will call it option 4. It will work in a large number of cases, hence the large number of places it has been used in. (I really don't know why I left it out, but is is problably because I tought about the following: I'm wondering about the case where it (option 4) won't work, let's say we have, void funcA(char ch) { WriteFile(h, &ch, sizeof(char), &num, NULL); } and void funcW(WCHAR ch) { WriteFile(h, &ch, sizeof(WCHAR), &num, NULL); } If we do the char -> WCHAR conversion, we will end up writing sizeof(WCHAR) bytes for every single character. In this simplest case, we could define a macro, #define WRITE_CH(ch, type) WriteFile(h, &ch, sizeof(type), &num, NULL) and this can be used in the functions, void funcA(char ch) { WRITE_CH(ch, char); } and void funcW(WCHAR ch) { WRITE_CH(ch, WCHAR); } In the case of similar bigger/longer functions, writing the macro is problably not the right thing to do. And this is where I end up duplicating code, eek. Greetings, Jaco

3 2

Re: Interrupts / Move most of int31 to winedos
by Andreas Mohr Nov. 5, 2002

Nov. 5, 2002

On Tue, Nov 05, 2002 at 06:47:35PM +0200, Jukka Heinonen wrote: > After this patch winedos contains almost complete int31 > emulation. What has not been moved to winedos is mostly > functions that require either W32S_WINE2APP or W32S_APP2WINE. > This makes me wonder whether Wine still needs to support WIN32S... Well, of course it does. Wine is supposed to run *all* reasonably new (i.e.: not "standard mode") Windows programs, and that does include Win32s IMHO.

1 0