October 2002 - Wine-devel - list.winehq.org

Re: Bug #321: dlls/msvct/vf[w]printf functions (Patch 2)
by Alexandre Julliard 29 Oct '02

29 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > I'm not sure if I should send the whole patch or just do increments for the > new stuff. At this point it is everything, including cleanups of the test > case and use of correct WideCharToMultiByte as suggested by Dimitri. In > additions the configure.ac patch for the dlls/msvcrt/tests/Makefile.in is added. > > As always, comments are very welcome to get this thing bedded down finally. - you can't use the libc printf to print unicode chars, the format is not the same - WideCharToMultiByte can output several characters for a single unicode char, you need to take that into account for buffer sizes - you cannot cast a WCHAR* into a CHAR* to convert the format to ASCII - there's no point in using strncat if you don't pass it the real size of the buffer - please don't copy code from MSDN, it is copyrighted by Microsoft. -- Alexandre Julliard julliard(a)winehq.com

3 4

RE: winapi update
by Patrik Stridvall 29 Oct '02

29 Oct '02

> > Why not, instead of complaining to people who doesn't > > (or only partly) listens, write some sort of mail "filter" > > the reformats the mail to one or more mail of a more > > appropriate format. Inline attachments and that sort of things... > > Oh, come on man, this _is_ silly. You are the only one sending > multiple patches per email, for crying out loud! :) Perhaps. Haven't checked. Anyway, I can't inline my patches the because Microsoft Outlook wraps the lines and I sure a lot of other people that use attachments have similar problems. So an attachment inliner might be useful nether the less...

2 1

Known listview bugs (take 2)
by Dimitrie O. Paun 29 Oct '02

29 Oct '02

Folks, After my latest X-series patches (currently at X6), I am aware of the following listview bugs: Yes, you read correctly: NONE. :) So I ask you for one of two things: -- bug reports or -- success stories Otherwise, I'm gonna declare listview the coolest, nicest, most huggable piece of code out there <g>. -- Dimi.

8 34

recent ListView problems
by post＠maikschulz.de 29 Oct '02

29 Oct '02

Hi, I'm using WinMX (www.winmx.com) rather frequently, currently version 3.30. Some two weeks ago, Wine HEAD displayed the ListView components from the search and transfer tabs perfectly, now the refresh/redrawing is messed up. The application documented the changes ListView has undergone in the recent months quite well, though (I'm updating Wine from CVS almost every day). Congratulations for implementing that rather complex control (almost) perfectly! Take care, -Maik

2 1

more desperate cries for help...
by Greg Turner 29 Oct '02

29 Oct '02

o I don't yet know how to properly raise and catch exceptions in wine. I see some examples, but I don't see any of try/finally, of which I am a big fan and would probably like to use. Is there a guide somewhere on how to do these things? o If we want MIDL generated code to compile in winelib, we are going to have to implement the RpcTryExcept and RpcTryFinally macros. I think I heard somewhere that, these are somewhat mysterious macros, i.e., their implementation is based on compiler magic instead of normal header files... how on earth shall we deal with that? I tried grepping the psdk header files and they map to __try, __except, __finally, and so on.... does wine have those? Thanks again for any assistance, -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

3 5

RE: winapi update
by Patrik Stridvall 29 Oct '02

29 Oct '02

> On October 29, 2002 09:32 am, Patrik Stridvall wrote: > > *** winapi_check > > > > * tools/winapi/win16.api, > > tools/winapi/win32.api: > > API file update. > > > > *** winapi_checked > > Patrik, please send different patches in different emails. I try to do that more and more. However in this case there are some logical relation between the patches. Every issue winapi_check reports results in either a patch to winapi_check (winapi_check.diff) or a patch to some source file (winapi_checked.diff). So if you wish to find any possible misstake I might have done your really should read both. OK, this time they might be not so useful to read both since they are almost 100% percent independant but that is not always when I do the winapi_check update. > See past discussions for rationale. I remember. :-) Speaking of which: Why not, instead of complaining to people who doesn't (or only partly) listens, write some sort of mail "filter" the reformats the mail to one or more mail of a more appropriate format. Inline attachments and that sort of things... Then we could have a wine-patches-filtered mailing list for people that like the patches in a specific format.

2 1

Re: 16-bit shell seperation
by Alexandre Julliard 29 Oct '02

29 Oct '02

"György 'Nog' Jeney" <nog(a)sdf.lonestar.org> writes: > ChangeLog: > * dlls/shell32/shell32_main.h > * dlls/shell32/shell.c > * dlls/shell32/shellreg.c > * dlls/shell32/Makefile.in > * dlls/shell32/shlexec.c > Seperate out 16-bit functions into seperate file. I have applied the registry stuff, but not ShellExecute16; this one will be need to be split properly so that the 32-bit version doesn't contain 16-bit stuff. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: winapi update
by Dimitrie O. Paun 29 Oct '02

29 Oct '02

On October 29, 2002 09:32 am, Patrik Stridvall wrote: > *** winapi_check > > * tools/winapi/win16.api, > tools/winapi/win32.api: > API file update. > > *** winapi_checked Patrik, please send different patches in different emails. See past discussions for rationale. -- Dimi.

1 0

RE: winsock + DSTRICT
by Patrik Stridvall 29 Oct '02

29 Oct '02

> Perhaps someone could check if SOCKET is really a 32bit type on 64bit > Windows. No it isn't. >From the latest SDK: typedef UINT_PTR SOCKET; A SOCKET is a pointer disguised as an integer and thus 64-bit on 64-bit platforms.

1 0

Re: more desperate cries for help...
by Dustin Navea 29 Oct '02

29 Oct '02

> --- Greg Turner <gmturner007(a)ameritech.net> wrote: > Beware of this one, It's long, and I've spliced > together at least two > (three?) posts, and probably quoted things > out-of-order... First off, everything seems in order to me... but thats just me... [-snip-] > to work, and may not get right? Why make getting > > it right harder by > > adding a lot of complexity, instead of adding > > infrastructure? > > good point, that seems like the logical way to > proceed. I totally agree here, we should always implement things and get them working properly before we get them working fast, or else we become like the evil empire ;) > Also: we could, indeed, implement wine-rpcss as you > mention. Since it's > not properly a "subsystem" in the MS sense of the > term, maybe it's > called "wine-epmap" but that's just semantics... > what you describe is > totally doable, and we could convert from some > low-level kludgy > implementation to an RPC-based implementation once > the necessary > marshalling was in place... I'll give this serious > thought. ok well if it is doable, i believe we should do it, why focus on the stuff that is _truely_ hard and that we may possibly not know jack shit about when we can get the _easier_ (not necessarily easy) stuff out of the way first, that will lead to a more solid codebase with which to work with. > Back to Ove: [snip] > heh, I know how that goes. Your insights, alone, > are helpful and > appreciated; get well, and we will collaborate on > this when you have > the time to devote to it. yes please, do get better soon, i may be coming down with something myself, my friend/roommate's ex may be the one that gave it to me too :( she is in the hospital now with an abcess on her tonsils, and i may have (somehow) gotten something from it, as I now have a sore throat... -Dustin P.S. nice quote Greg ;) __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

2 1