wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Re: Wine FAQ - call for a volunteer
by Ulf Dambacher 07 Nov '02

07 Nov '02

Just one tip: Why not use a wiki-Engine to creaate/maintain a faq, like e.g. www.squirrelmail.net does? I recommend phpwiki (http://phpwiki.sourceforge.net/) This way users can maintain the faq and it is most up to date! Greetings Ulf

3 2

Pls help me.
by yf 07 Nov '02

07 Nov '02

When I using wine start a winapp, it first download some data and then save it to the disk. But when save the data, it always says "Disk full while accessing C:\south\Base.map. What's the matter with it? How could I resolve it? Pls give me some hints? Best regards. /yf

2 1

Re: [PATCHLET] DeleteFile With Empty Paths
by Marcus Meissner 07 Nov '02

07 Nov '02

On Thu, Nov 07, 2002 at 02:18:20AM -0800, Ryan Cumming wrote: > Hi, > > KaZaA Lite 2.0 calls DeleteFile with an empty path at shutdown, which triggers > ERR("Empty path passed\n"). It seems a bit silly to call that an error, so > this patch changes the message to a warning. It also does a > SetLastError(ERROR_FILE_NOT_FOUND) in that case, which is consistant with > Windows XP. Can you also create a testcase for this problem? Ciao, Marcus

1 0

Wine 0.9 TODO v0.2
by Dimitrie O. Paun 07 Nov '02

07 Nov '02

Folks, This time in HTML & Technicolor, at: http://www.dssd.ca/Wine-0.9-TODO.html Please take a look, and let me know if you think anything needs to change. If you are listed there on a task, a status update would be more than appreciated. If you feel like working on something, I would like to know to add you in there. NOTE: most tasks don't require coding, so don't be shy, and step up to the challenge. ;) -- Dimi.

1 0

Re: Interrupts / Move most of int31 to winedos
by Jukka Heinonen 06 Nov '02

06 Nov '02

Andreas Mohr wrote: > 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. Sure, I know that (I'm working on DPMI32 which isn't for standard mode Windows programs), I was probably being a bit unclear about what I was wondering about. It is quite difficult to find any information about Win32s nowadays and everything I have found was suggesting that Win32s was for running Win32 applications on Win16. Since Wine does run Win32 applications directly it just made me wonder whether Win32s support is something that was once needed when Wine only had Win16 support. But, since I know very little about Win32s, I can only wonder. It all depends on how Win32s applications differ from Win32 and Win16 applications. The existence of Win32s dlls seems to suggest that Win32s applications are not regular Win32 applications as well as the text in "msdos/vxd.c" which talks about some strange pointer mangling required with Win32s applications. This mangling is probably something that is only required if Wine supports official Win32s dlls. Which makes me wonder if Win32s dlls provided by Wine actually do work because they don't seem to do any pointer mangling. Well, it could be that Win32s applications do this pointer mangling internally. Anyway, I seem to have answered myself. If Wine is going to support Win32s applications using both builtin and official Win32s dlls, it needs pointer mangling. I just have to figure out how the required offset can be accessed from multiple dlls because I would really like to have all the interrupt handlers in one place. I still think that all the tricks required in order to support official Win32s dlls are quite ugly: all the routines that use linear addresses and are called directly by Win32s applications need to do pointer mangling and msdos/vxd.c actually modifies the official dlls in order to work around some problems. But since this most likely works already, I don't think I want to change anything. -- Jukka Heinonen <http://www.iki.fi/jhei/>

8 14

Re: Wine history
by Robert Amstadt 06 Nov '02

06 Nov '02

> If you live near one of these people, buy them a beer. If any of the current developers live in or around San Jose, CA, U.S., I'd be happy to buy you a beer. Thank you, Dan, for digging up that history. It is always wierd though to read my past words and realize that someone is archiving them. ----- Bob Amstadt http://www.amstadt.com/~bob bob(a)amstadt.com

1 0

Wine history
by Dan Kegel 06 Nov '02

06 Nov '02

Here are a few early posts: ============================ http://groups.google.com/groups?selm=1993Jul2.173648.3202%40amscons.com Newsgroups: comp.os.linux From: bob(a)amscons.com (Bob Amstadt) Subject: Re: Impressions of WABI/Univel vs Linux References: <C9JoGx.IMM(a)news2.cis.umn.edu> Organization: Amstadt Consulting Group Date: Fri, 2 Jul 1993 17:36:48 GMT X-Newsreader: Tin 1.1 PL4 Message-ID: <1993Jul2.173648.3202(a)amscons.com> Lines: 7 Of course, for those of you who are interested in running Windows programs there is an effort in progress to create something similar to Sun's WABI. There is an activists channel, "WABI", for discussion of this project. There is need for many volunteers to complete this project. -- Bob Amstadt bob(a)amscons.com ============================ http://groups.google.com/groups?selm=1993Aug5.153058.1530%40amscons.com Newsgroups: comp.windows.x.i386unix From: bob(a)amscons.com (Bob Amstadt) Subject: Re: WABI how good is it? References: <1993Aug4.134724.24562(a)jarvis.csri.toronto.edu> <CB96AH.2GDK(a)austin.ibm.com> Organization: Amstadt Consulting Group Date: Thu, 5 Aug 1993 15:30:58 GMT Message-ID: <1993Aug5.153058.1530(a)amscons.com> Lines: 27 In <CB96AH.2GDK(a)austin.ibm.com> guyd(a)austin.ibm.com (Guy Dawson) writes: >In article <1993Aug4.134724.24562(a)jarvis.csri.toronto.edu>, arisz(a)csri.toronto.edu (Aris Zakinthinos) writes: >> I have been reading in the local papers about WABI being able to >> translate MS Windows API calls into X calls in real time. Has anybody >> tried it? Is it any good? How about those calls that somehow made it >> into the code but not the docs (i.e. the undocumented calls). I am >> curious to here what it is like. If this realy does work then I may >> never use MS Windows again!!!! How is it being distributed? >> >It's not available yet! >It's a Windows run time enviroment for Unix boxes - Sun started it and >are going to produce it for their boxes. I don't know who else is looking >to support it... Well, those of us in the Linux camp are working on a similar project. It could be extended to run on other Unix operating systems if they would be willing to provide us with the necessary call to manipulate the LDT for the process. Perhaps someone using one of the BSD derivatives would like to get involved with our project? Questions about this project may be directed toward me. -- Bob Amstadt bob(a)amscons.com ============================ http://groups.google.com/groups?selm=1993Aug17.200321.4496%40amscons.com Newsgroups: comp.os.linux.misc From: bob(a)amscons.com (Bob Amstadt) Subject: Re: WABI/WINAPI - a Retraction References: <1993Aug17.143450.22682(a)cc.gatech.edu> Organization: Amstadt Consulting Group Date: Tue, 17 Aug 1993 20:03:21 GMT Message-ID: <1993Aug17.200321.4496(a)amscons.com> Lines: 19 In <1993Aug17.143450.22682(a)cc.gatech.edu> byron(a)cc.gatech.edu (Byron A Jeff) writes: >2) The WABI folks aren't talking. I have not seen any software yet. Well, considering the fact that we only got started in June, I think we are pretty far along. We don't have any off-the-shelf binaries running yet, but we can run binaries that contain only implemented API functions. We are always looking for more help. Only four people have provided code to the current emulator. I would gues that 80% of that code has been written by two people. If you would like to join the effort, join the linux-activists WABI channel. The name of the project is now Wine, and we have a directory under /pub/linux/ALPHA on tsx-11. Currently there is only a README file which contains information about the status of the project. -- Bob Amstadt bob(a)amscons.com ============================ http://groups.google.com/groups?selm=26ai6a%24mob%40samba.oit.unc.edu From: bob(a)amscons.com (Bob Amstadt) Newsgroups: comp.os.linux.announce Subject: Wine project status update Followup-To: comp.os.linux.misc Date: 4 Sep 1993 17:10:34 GMT Organization: Amstadt Consulting Group Lines: 84 Approved: linux-announce(a)tc.cornell.edu (Matt Welsh) Message-ID: <26ai6a$mob(a)samba.oit.unc.edu> Reply-To: bob(a)amscons.com (Bob Amstadt) NNTP-Posting-Host: calypso.oit.unc.edu Summary: You like the Wine? The Wine is good? I get you more Wine. Keywords: WABI Wine MS Windows Emulator Originator: mdw@sunSITE Numerous people have requested that the project status of Wine be posted regularly. For the benifit of those people, I am posting the latest README file that I have uploaded to tsx-11... The Wine project for linux is an attempt to write something with similar functionality to the WABI that was developed by Sun. The basic goal is to be able to take a MS-Windows binary and run it under Linux with X-Windows running. The finished product will essentiaily consist of two parts: a) A program loader, which will load the Windows binary into the virtual memory of the linux process, provide a means for adjusting the ldt of the processor so that the 16-bit segments that are typically used with Windows binaries will work correctly, and provide a means for calling the Windows binary in the first place, allowing the Windows binary to call back to the 32-bit mode program, and finally allow the 32-bit mode program to call back again to the Windows binary (i.e. Windows callbacks). In each case, the arguments being passed wil have to be pulled from the appropriate stack and loaded on to the other stack (there will be a 16 bit and a 32 bit stack). Finally some application specfic DLL libraries will have to be loaded, and dynamic linking will have to be performed. b) The second part of the finished product is an emulation library, which takes calls to Windows functions, and somehow translates these into calls to X11 in one fashion or another, so that equivalent functionality is achieved. It should be pointed out that the Windows binary will be running directly - there will be no need for machine level emulation of the instructions. Sun has reported better performance with their version of WABI than is actually achieved under MS-Windows - theoretically the same result is possible under linux. The project got started as a result of discussions on comp.os.linux in early June of 1993. A mail channel was set up for discussions, and this directory was created. At the moment, all of the files that are uploaded are in the private directory in a hidden directory. The reason for this is that the program is really only of use to developers right now. Once something is ready for public consumption, it will be uploaded to a publicly visible directory. The final product will almost certainly be under the GNU Public License (or GPL for short). If you are interested in getting involved in this project, join the linux activists' WABI channel. If you have never joined a channel before, send mail to linux-activists-request(a)niksul.hut.fi. It will reply with a help message. New releases are approximately every Tuesday. All releases are announced to the WABI channel. Also, I will do my best to answer any question mailed to me. My address is "bob(a)amscons.com". *************************************************************** Status Report - September 3, 1993 Windows Solitaire is barely playable for the first time today. Special thanks go to Alexandre Julliard, Eric Youngdale, David Metcalfe and Peter MacDonald for their work on this project. If you live near one of these people, buy them a beer. It looks like the Linux kernel modifications are nearing completion. Hopefully the next Linux kernel (0.99.13 ?) will not require patching to run Wine. The loader portion is nearing completion. Sample Windows binaries are loaded correctly into memory, dynamicly linked and so forth. The 16/32 bit call interface is fairly complete. There are still a few features that remain to be added before it can be considered "done", but it is at the point where it is actually useful. Resource loading is only partially complete. A very minimal version of the emulation library has been merged with the loader. Windows can be created, DC's may be used, bitmaps are handled, text drawing is implemented, and a preliminary implementation of menus has been created. Bugs are still present in many of the implemented functions, but things are starting to look up. -- Bob Amstadt bob(a)amscons.com -- Send submissions for comp.os.linux.announce to: linux-announce(a)tc.cornell.edu

1 0

Forgive the intrusion
by Robert Amstadt 06 Nov '02

06 Nov '02

Please don't let me distract you from your important work, but Thomas Wickline asked me to stop in and say hello to all of you. I understand that we are approaching the 10 year anniversary of Wine. That is a remarkable feat. All of you should be proud to be contributing to this effort. It is an amazing piece of software. Though many of the names I see on the WineHQ web site are new to me. I continue to see Alexandre Julliard's name on this work. I had the pleasure of meeting Alexandre many years ago and I am so glad to see that he continues the work after so many years. Alexandre, if you read this, thank you very much for all that you have done for free software. Thank you to the rest of you as well. Wine has been a team effort from the start and is so successful because it is a team effort. When I stepped down from leading this project, I knew it would continue due to the efforts of all the people that have helped along the way. It not only has continued, but it clearly thrives. I'm amazed at the number of people that know what Wine is. Congratulations to all of you Wine developers. You are amazing people. ----- Bob Amstadt http://www.amstadt.com/~bob bob(a)amstadt.com

2 1

Re: templates support to commdlg ChooseFont
by Shachar Shemesh 06 Nov '02

06 Nov '02

One more bug: FIXME still reports the CF_ENABLETEMPLATE flag as non-supported. Shachar Shemesh wrote: > ChangeLog: > Shachar Shemesh <winecode(a)sun.consumer.org.il> > > Todo: > > * Implement support for the scripts selection. > o Enum the scripts the font supports, and display the list > accordingly. > o Make the sample text use characters from the selected script > (today SOME resources included the local text, which is not > the correct behaviour). > o Implement the Unicode version of script selection properly. > > Bugs: > > * Non functional changes were only applied to the English resource. > I'm sorry, I'm sick (literally - I'm ill), and my sed skills are > not very good. I only performed the changes that were required in > order to keep the code functioning. > * The windows method is to pass stc5 not visible, and the commdlg > code created a BUTTON with the same ID at the same place. I'm not > sure why that is, probably so things will be visibily pleasing. > Our code, if passed not visible, will not display the sample text. > > > > dlls/commdlg/cdlg_En.rc > > * Changed all numeric resources in ChooseFont to labels for better > readability. > > dlls/commdlg/cdlg_*.rc > > * Changed control #1093 (sample text) to stc5 (1092) to convert to > Windows compatible numbers. > > dlls/commdlg/fontdlg.c > > * Changed all handling of stc6 (1093) to atc5 (1092) so that will be > compatible with Windows resource numbers. > * Added code to load the user's resources rather than our own if > CF_ENABLETEMPLATE is passed in "flags". > > > >

1 0

IDL/header issues
by Ove Kaaven 06 Nov '02

06 Nov '02

Now WIDL is good enough to generate a drop-in replacement for Wine's wtypes.h (attached) from a suitably crafted Wine-compatible wtypes.idl (also attached). I've included all the definitions that were already in Wine's wtypes.h (but I was too lazy to do everything that's in Microsoft's wtypes.idl yet). What do you think, is this good enough to go into Wine? Are there some desirable changes to widl or wtypes.idl? And should IDL files go into the main include dir along with the other Win32 headers? IDL-generated files would also eventually obsolete all the current wine/obj_*.h files, but those obj_* files seem to be somewhat more logically structured than MS's own IDL files, should we craft Wine's IDL files accordingly, and maybe have some top-level .idl files in include/ and some sub-.idl files under include/wine/, like it's done now in e.g. objidl.h? Note that I will work on ReWind, not directly on Wine, so I probably won't be able to submit massive "change all files to include this instead of that" patches (that apply to Wine) with any new files.

3 13

RE: Wine headers mismatch
by Patrik Stridvall 06 Nov '02

06 Nov '02

> On November 6, 2002 02:38 pm, Patrik Stridvall wrote: > > Fixed mismatches between the Wine headers and the Microsoft headers. > > Patrick, what's the status of compiling stuff on Windows? The tests compiles fine (except for ntdll if the Microsoft headers are used). Some fails on Windows when running, but I haven't had time to look at it very much. As for the normal dlls: Well some compile most don't. Quite a lot of work remains. However the compilation instructure generated by msvcmaker work quite well, so if anybody want to help they can. I have a lot of kludges in my MSVC tree so you might run into some problems though...

2 1

Re: Wine headers mismatch
by Dimitrie O. Paun 06 Nov '02

06 Nov '02

On November 6, 2002 02:38 pm, Patrik Stridvall wrote: > Fixed mismatches between the Wine headers and the Microsoft headers. Patrick, what's the status of compiling stuff on Windows? -- Dimi.

1 0

Re: PATCH: DispCallFunc
by Dimitrie O. Paun 06 Nov '02

06 Nov '02

On November 6, 2002 01:40 pm, Marcus Meissner wrote: > + > + FIXME("(%p, %ld, %d, %d, %d, %p, %p, %p)\n", > + pvInstance, oVft, cc, vtReturn, cActuals, prgvt, prgpvarg, pvargResult + ); Why is this one a FIXME, and not a TRACE? [snip] > + /* FIXME: Must handle pvargResult. How? */ Isn't it better to issue a FIXME here, if pvargResult is not NULL? -- Dimi.

2 1

Re: OT: Wine history
by Brian Vincent 06 Nov '02

06 Nov '02

> What's the history of Wine? Hmm. I actually started on something like this. Google's groups are a great way to find info. Some of the stuff I started on was the very early years - 1993 - 1995. I'm sure Marcus or Alexandre could fill in the blanks after that. As far as Bob goes, there was a posting back in '96 or '98 about his involvement with TWIN. Weird fact of the day: Miguel de Icaza was cited as an early contributor to Wine. -Brian Vincent vinn(a)theshell.com

3 2

I dont mean to start a flame war, but...
by Dustin Navea 06 Nov '02

06 Nov '02

Mr. Amstadt, I just was marvelling at seeing you on the list ;) and the question happened to pop into my head, what do you think about the whole wine relicensing ordeal, and TransGaming trying to get at the LGPL-licensed code? -Dustin Navea WebHosting Tech Support, RackShack.net Internet Services Minor Code Contributor/Better Bugfinder, winehq.com IRC NetAdmin, irc.blynk.net (down) __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

3 2

Re: ComputerName
by Dmitry Timoshkov 06 Nov '02

06 Nov '02

"Martin Wilck" <Martin.Wilck(a)Fujitsu-Siemens.com> wrote: > +/****************************************************************************** > + * netbios_char (INTERNAL) > + */ > +static WCHAR netbios_char ( WCHAR wc ) > +{ > + static const WCHAR special[] = {'!','@','#','$','%','^','&','\'',')','(','-','_','{','}','~'}; > + static const WCHAR deflt = '_'; > + int i; > + > + if ( isalnumW ( wc ) ) return wc; > + for ( i = 0; i < sizeof (special); i++ ) > + if ( wc == special[i] ) return wc; > + return deflt; > +} Shouldn't be sizeof(special) above divided by sizeof(WCHAR)? -- Dmitry.

2 1

Re: Games
by Mark Hannessen 06 Nov '02

06 Nov '02

here we are. Zsolt about Safedisc 1.x > When the patch was published, there was a discussion, and the conclusion was > that the code is very probably legal, and is not against DMCA > Are you sure about the above statements? Have you checked that, or it is > just your opinion? Carlos words regarding copy protection: > You aren't giving hints to decrypt some code, simply implementing the > win32 API, and sometimes implementing a PC architecture, it is far away > of decrypt code ;). well i'am not a lawyer, so i guess i was probably wrong about copyprotection being illegal after all. > Zsolt also said he could provide a safedisc patch against the current cvs. Zsolt, could you give us a status of your safedisc patch ? does it work with all winver versions or is this one limited to nt40 ? ( most games do not run in nt40 mode ) is it safedisc 1.x only or safedisc 2.x as well. anyway, any work on copyprotection is very very usefull for everbody. so please impent everything you have. Mark Hannessen

9 11

Re:COM Error
by kevin 06 Nov '02

06 Nov '02

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

2 1

RE: Big Problem compiling gdi tests
by Patrik Stridvall 06 Nov '02

06 Nov '02

> I don't if it's related to me, but I got a memory problem when > compiling the gdi tests today. > > I know the C code is lot bigger than any other one but I > think there is > an infinite loop somewhere.According to the following report, > gcc tries > to allocate 340 Mo (if succeeded, could be more...) > > Using RedHat 8.0 updated, gcc 3.2.7 on a Athlon 1600+ > > make[3]: Entre dans le répertoire `/home/wine/dlls/gdi/tests' > gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall > -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DNONAMELESSUNION > -DNONAMELESSSTRUCT -D_REENTRANT -o generated.o generated.c > > cc1: Cannot allocate 188247240 bytes after allocating 15480320 bytes Hmm. It work fine if you remove -O2. I almost never compile Wine with optimization so I haven't detected it. OK. I will see what I can do. It takes A LOT longer to compile with -O2 on my computer.

2 1

How to debug destroyed call stack?
by Fabian Cenedese 06 Nov '02

06 Nov '02

Hi I have a program that crashes at startup. The backtrace shows only one entry (and obviously a wrong one). What's the best way to find this error? Is it possible that my program can write into wine's memory? It runs fine in Windows so I don't think that there are many flaws in it (though still possible of course :) It's a multithreaded ocx so it's not that easy to debug. It happens in various versions from cvs. Thanks for any hints. bye Fabi

1 0

Re: Lost Wages (round 2)
by Dustin Navea 06 Nov '02

06 Nov '02

--- Jeremy Newman <jnewman(a)codeweavers.com> wrote: > On Tue, 2002-11-05 at 15:00, Dustin Navea wrote: > > One thing I noticed is that the Classic Theme's Text on the word > Development > > in the graphic at the top is the same color as the background making it > > invisible, therefore making it look like: > > Wine HQ > > I noticed this with Netscape 4. The logo is a PNG, with the background > transparent. But Netscape 4 (and some other browsers) do not support > opacity in PNG. To see what the logo is supposed to look like when PNG > is supported properly, load up in Mozilla 1+. > It showed this in IE5.5, I am at work without access to a linux box so I cant check it until tonight > I am of a mindset to not support Netscape 4. The whole JPG/Gif issues > notwithstanding. > > > Also, I still say there should be some other color options besides dark > red, > > that color almost makes my eyes melt out of their sockets. >;) I would > say > > add a white wine skin and maybe a champaigne or a mad dog (the malt > liquor) > > skin... ;) > > I'll make some skin docs when I'm done. I'm more concerned with the > backend code ATM. > lol i know it was a just a suggestion for your todo -Dustin __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

7 11

Fwd: WINE virus thing
by Dimitrie O. Paun 06 Nov '02

06 Nov '02

---------- 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 06 Nov '02

06 Nov '02

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 06 Nov '02

06 Nov '02

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 06 Nov '02

06 Nov '02

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel