January 2002 - Wine-Devel - list.winehq.org

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > I believe that C tests should be ANSI/UNICODE independent as much as > possible, and then, at compile time, one can choose to compile either > for ANSI (default) or for UNICODE. No, *please* don't do that. These Unicode macros are an ugliness that we should stay away from; in fact we probably want to make it impossible to use them, just like we do inside Wine itself. Please write tests to call both A and W functions explicitly; it really isn't much more work than testing a single variant anyway. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Can you suggest more reliable way to detect if test > runs on Wine? I'll work on that. > One more important change in C framework is support of > Unicode in testing. > Dimitry, can you look at it? See how it is used in > sysparams.c, search for "has_unicode" function call. > I'm interested in your comments. I don't think we want that. And anyway we don't emulate non-Unicode platform properly (i.e. Unicode calls that fail under win95 will succeed under Wine even with -winver win95). I think we should simply call Unicode functions on all platforms and have the tests deal with the possible errors. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Francois Gouget

On Thu, 17 Jan 2002, Andriy Palamarchuk wrote: > > --- "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > > On Thu, 17 Jan 2002, Dmitry Timoshkov wrote: > > > > For tests, I think we should in fact use > > SystemParametersInfo, and then > > compile the test twice -- for A and for W. Both > > versions should behave the > > same, right? > > IMHO (after consulting with MSDN) you can write A<->W > portable code only with MFC. > Let me know if I'm wrong. You are wrong (or the MSDN is trying to lure you into using the MFC by making false claims). Your code should never use char or WCHAR, strcpy, and things like that. Instead it should use the things defined in 'tchar.h': * TCHAR maps to char or WCHAR * _tcscpy maps to strcpy or wcscpy * _tcslen maps to strlen or wcslen * _TEOF maps to EOF or WEOF * _tWinMain maps to WinMain or wWinMain ... and then the regular structures and APIs: * xxx maps to xxxA or xxxW etc, etc. The problem will be with Winelib's Unicode support though. It has made progress but there may still be some problems and it depends on compiler support. But at least, this will allow us to test it which is a good thing. I believe that C tests should be ANSI/UNICODE independent as much as possible, and then, at compile time, one can choose to compile either for ANSI (default) or for UNICODE. If we can have a test framework that can compile and run a single test twice, once for ANSI and once for UNICODE, then it's perfect. But otherwise the above solution is good enough. Most people will compile and run the test in ANSI mode and some people will compile and run them in Unicode mode, and that's probably good enough. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Jan. 17, 2002

Re: HEAP_ZERO_MEMORY was: Re: Prevent passing uninitialised string to WARN

by Bill Medland

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote in message news:15431.12895.407432.24677(a)hertz.ikp.physik.tu-darmstadt.de... > >>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: > > Medland,> Bill Medland (medbi01(a)accpac.com) Prevent trying to handle > Medland,> uninitialised memory as a string. > > Medland,> Index: wine/loader/module.c > Medland,> =================================================================== > Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving > Medland,> revision 1.144 diff -u -r1.144 module.c --- > Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++ > Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@ > > Medland,> filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 ); > Medland,> if ( !filename ) return NULL; > Medland,> + *filename = 0; /* Just in case > > Wouldn't HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0? > > This would apply to many places. > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > Take your pick. The fix is almost certainly fixing something that is only theoretically possible and will never happen. As far as I am concerned all I want is to ensure that filename is a valid string, in case it gets passed to the snprintf or whatever sits below WARN before the core code actually puts a string in it. Setting the first character is good enough for that. It ought to be faster too. (What this is hiding, of course, is the fact that Bill Medland doesn't really know how to program in Windows and didn't know about HEAP_ZERO_MEMORY). I think you are right that there are a lot of places where we are not initialising memory that we ought to. That then gets into the whole subject of defensive programming and just how much we should do it. I noticed a thing in the New York Times today suggesting that Microsoft are possibly going to be a little more proactive in the area of robust coding. Anyway, thanks for the education ;-) Bill

Jan. 17, 2002

Re: HEAP_ZERO_MEMORY was: Re: Prevent passing uninitialised string to WARN

by Francois Gouget

On Thu, 17 Jan 2002, Uwe Bonnes wrote: > >>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: > > Medland,> Bill Medland (medbi01(a)accpac.com) Prevent trying to handle > Medland,> uninitialised memory as a string. > > Medland,> Index: wine/loader/module.c > Medland,> =================================================================== > Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving > Medland,> revision 1.144 diff -u -r1.144 module.c --- > Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++ > Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@ > > Medland,> filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 ); > Medland,> if ( !filename ) return NULL; > Medland,> + *filename = 0; /* Just in case > > Wouldn't HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0? I like the '*filename = 0' solution better as HEAP_ZERO_MEMORY would overinitialize the buffer (wasting CPU time and memory bandwidth). In fact I would like the following even better :-) *filename = '\0'; (assuming filename is a char*) But that's just a question of style. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

Jan. 17, 2002

HEAP_ZERO_MEMORY was: Re: Prevent passing uninitialised string to WARN

by Uwe Bonnes

>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: Medland,> Bill Medland (medbi01(a)accpac.com) Prevent trying to handle Medland,> uninitialised memory as a string. Medland,> Index: wine/loader/module.c Medland,> =================================================================== Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving Medland,> revision 1.144 diff -u -r1.144 module.c --- Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++ Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@ Medland,> filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 ); Medland,> if ( !filename ) return NULL; Medland,> + *filename = 0; /* Just in case Wouldn't HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0? This would apply to many places. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

--- "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > On Thu, 17 Jan 2002, Dmitry Timoshkov wrote: > > For tests, I think we should in fact use > SystemParametersInfo, and then > compile the test twice -- for A and for W. Both > versions should behave the > same, right? IMHO (after consulting with MSDN) you can write A<->W portable code only with MFC. Let me know if I'm wrong. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 17, 2002

RE: What are you really aiming to do with winetest?

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So what you basicly want is something like: > > > > my %return_type_exceptions; > > > > $return_type_exceptions{"foo"} = { > > Bar => "str", > > Baz => "ptr" > > }; > > > > $return_type_exceptions{"bar"} = { > > Foo => "str" > > }; > > > Yes, that would work fine for now. OK. I made a script (adapted winapi_extract) to do this (attached). Output attached as well, but you can regenerate it by doing tools/winapi/winapi_extract in the topsrcdir. I realized that when I was at it I could output the argument types as well and thus having a hash table that can be given to wine::declare directly. Here is also a script make_modules that generates modules to use this directly and thus there is no need to any spec2pm any longer. However I'm not postive that we want to have seperate include for constants and functions. Perhaps it would be better if people used to C could just do use winuser; instead of #include "winuser.h" and not have to do any additional use user32; as well. Oh, well, I don't really have any strong feelings in any direction. But it would be easier if you told me how you wanted it. Oh BTW: What is your opinion on having special Perl adapted versions of some functions like: sub GlobalGetAtomNameA { my $atom = shift; my $buffer = "\0" x 256; # FIXME: Fixed buffer length my $length = &kernel32::GlobalGetAtomNameA($atom, \$buffer, length($buffer)); return substr($buffer, 0, $length); } Should we have them as the default imported function in say kernel32.pm or should each test that wants a easier to use version declare it in the test itself.

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Dimitrie O. Paun

On Thu, 17 Jan 2002, Dmitry Timoshkov wrote: > I would suggest to explicitly use A and W suffixes to avoid confusion: > not just SystemParametersInfo, but SystemParametersInfoA. For tests, I think we should in fact use SystemParametersInfo, and then compile the test twice -- for A and for W. Both versions should behave the same, right? If we make people write the same code twice (for A and for W), we will either (1) get no tests, or (2) have tests that exercise only one of the two cases. -- Dimi.

Jan. 17, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

On 17 Jan 2002, Martin Wilck wrote: > > As you may see from the different email address, I am currently off work > - I'll look deeper into your traces next week. > Many thanks for generating them, anyway. > > >From a first glance, it seems that the app doesn't do overlapped recv(). > (lpOverlapped & completion_func are always NULL), so there should > actually be no difference (well I'm now using recvmsg() instead of > recv(), and the overhead for 16 bit Winsock apps is definitely larger, > but I cannot see why that should slow everything down that much). > Perhaps I screwed up the blocking semantics of non-overlapped IO. That's what it looks like to me. > > Have you generated the traces under exactly the same conditions? > Can you explain what exactly you did? > > Martin > To have exactly the same data being transferred, I would have to control both ends of the line, I think. I didn't do that. What exactly do you mean, "what exactly I did?" ;-) I have 2 versions of what is essentially the same app, a - well, functionally, it is sendmail/fetchmail: juno 2 and juno 4. I am not sure what protocol[s] it uses, but the app's internal logs mention postoffice, so maybe some perversion of POP3 or so. Anyway, start the app and it connects to its server, sends any mail queued to go out, and receives any mail the server has, and any ads the server sees fit to give it. I think it compresses/decompresses the data itself. I applied the patches. I sent this by juno 4 without trace: Message-ID: <20020116.183513.134657248.0.lawson_whitney(a)juno.com> The app reported it failed to fetch my mail, try again later. I tried again with a winsock trace, and it succeeded, producing socks.gz I then ran juno 2 with trace, producing winsock.gz. I reversed the patches, which took some time to compile and traced juno 4 again, producing sox.gz... Put it this way: socks.gz and sox.gz are exactly the same app with and without the patches. winsock.gz and winsox.gz are a different version of the app, with and without the patches. Actual traffic is different for each session, but the pattern for each should be the same, if that makes any sense to you. Lawson

Jan. 17, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by Martin Wilck

As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway. >From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO. Have you generated the traces under exactly the same conditions? Can you explain what exactly you did? Martin

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > One more important change in C framework is support of > Unicode in testing. > Dimitry, can you look at it? See how it is used in > sysparams.c, search for "has_unicode" function call. > I'm interested in your comments. I would suggest to explicitly use A and W suffixes to avoid confusion: not just SystemParametersInfo, but SystemParametersInfoA. -- Dmitry.

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

Alexandre Julliard wrote: > You don't need to > set the variable when running make test, but you have the possibility > to set it if you want to override the default for whatever reason. > I don't see why we should impose a less flexible solution that won't > be more robust anyway. Alexandre, by your suggestion I implemented the switch, but left automated platform detection in place. Platform detection will work when the environment variable is not set or set to unknown value. Can you suggest more reliable way to detect if test runs on Wine? One more important change in C framework is support of Unicode in testing. Dimitry, can you look at it? See how it is used in sysparams.c, search for "has_unicode" function call. I'm interested in your comments. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 17, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Andriy Palamarchuk

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > > > I mean real Windows 95. Tests should be compiled > and > > run on all the Windows platforms to insure their > > correctness. > > > > Is there a way to check whether given version of > Win32 > > supports UNICODE? > > Probably some tests should be marked as expected to > fail on 9x, NT4, > 2000 to predict failures on particular version of > windows. Please > take into account that there are considerable number > of API calls > are not supported on one of Windows incarnations > (unicode, thunks, > crypto API, native APIs, additions to the server > versions, etc.). Yes, of course. Conditional tests will be enough for this kind of things. I'll create a macro for this in the C testing framework. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 17, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > I mean real Windows 95. Tests should be compiled and > run on all the Windows platforms to insure their > correctness. > > Is there a way to check whether given version of Win32 > supports UNICODE? Probably some tests should be marked as expected to fail on 9x, NT4, 2000 to predict failures on particular version of windows. Please take into account that there are considerable number of API calls are not supported on one of Windows incarnations (unicode, thunks, crypto API, native APIs, additions to the server versions, etc.). -- Dmitry.

Jan. 16, 2002

Re: DOSFS_ToFCBFormat Bug Fix

by David Elliott

On 2002.01.14 13:21 Francois Gouget wrote: > On Mon, 14 Jan 2002, Ove Kaaven wrote: > > > > > On Sun, 13 Jan 2002 ccrayne(a)crayne.org wrote: > > > > > Change Log: > > > files/dos_fs.c > > > ccrayne(a)crayne.org > > > Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." > instead > > > of as "*.*" > > > > This sounds like intended behaviour. Under real DOS, "*" really means > > "*.". The user must type "*.*" to get all files. (This is the stuff > that > > used to confuse DOS users converting to Linux - "*.*" no longer meant > all > > files...) > > Strange because if I open a 'dos box' in Win95 or NT4, and I type > 'dir *' I get a list of all the files, including those that have an > extension like "autoexec.bat". > Yup! With long filenames windows treats the extension like UNIX does. That is a "dir *" will in fact show all files in the directory when command.com is running under windows. When it's not running under windows a "dir *" is equivilent to a "dir *." As for dir *.* showing filenames not containing a dot... well, I think this is because short names are still around and therefore when you look up the file as an 8.3 name *.* does match it because a file named "FOOBAR" will have the shortname equivilant to "FOOBAR." Anybody know what happens under NT if you turn off short name generation, then make a file named foobar and then do a dir *.* in that directory? I am guessing MS has this figured out and when the windows APIs see "*.*" they convert it to a simple "*". Of course I could be wrong and it may in fact simply not show the file since *.* would not match it by standard wildcard rules as it has no shortname with an implicit dot and the longname doesn't contain a dot. Should be simple enough to test. Load up NT or 2k, mod the reg to disable short filenames, reboot, make the file then do a dir /x (I think it is /x) to show both long and short filenames and verify it does not have a SFN. Then dir *.* and see if it finds it. -Dave

Jan. 16, 2002

Re: user32.TrackMouseEvent

by David Elliott

On 2002.01.15 11:37 Rein Klazes wrote: > hi, > > to implement user32.TrackMouseEvent: > > Changelog: > dlls/comctl32/ : commctrl.c > dlls/user/ : user32.spec > windows/ : input.c > include/ : winuser.h > > Move the implementation of comctl32._TrackMouseEvent to > user32.TrackMouseEvent and call this function in accordance > with the specs. > Man, it must not be my week. I did the exact same thing two days ago ('cept I put the TME stuff into windows/tme.c instead of adding it to input.c). Was part of making IE work as mentioned in my last mail regarding the stumbling block I hit with DPA that Aric has figured out. That'll teach me to leave patches sitting around in my tree for a couple days. -Dave

Jan. 16, 2002

Re: common controls updown patch

by David Elliott

On 2002.01.14 14:45 Shane Shields wrote: > hi all > > this is just a little patch to fix the UPDOWN_GetArrowRect function where > the > midpoint is calculated by adding 1 to odd numbers. before it just added 1 > to > every number now it tests for odd numbers before adding. > > Shane > > Thanks Dan for the tips > > Changelog: > > Shane Shields locutus(a)all.at > > updown.c UPDOWN_GetArrowRect function > added odd number checking > --- ./dlls/comctl32/updown.c.orig Mon Jan 14 20:35:07 2002 > +++ ./dlls/comctl32/updown.c Sun Jan 13 17:28:18 2002 > @@ -1,4 +1,4 @@ > -/* > +/* > * Updown control > * > * Copyright 1997 Dimitrie O. Paun > @@ -176,14 +176,16 @@ > * round the uneven numbers by adding 1. > */ > if (dwStyle & UDS_HORZ) { > - len = rect->right - rect->left + 1; /* compute the width */ > + len = rect->right - rect->left; /* compute the width */ > + if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */ > if (incr) > - rect->left = rect->left + len/2; > + rect->left = rect->left + len/2; > else > rect->right = rect->left + len/2; > } > else { > - len = rect->bottom - rect->top + 1; /* compute the height */ > + len = rect->bottom - rect->top; /* compute the height */ > + if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */ > if (incr) > rect->bottom = rect->top + len/2; > else > The remainder of any even number divided by two is 0, the remainder of any odd number divided by two is 1. Knowing this doesn't: len+=(len%2); make more sense. Leave the comment as is for clarity if you wish. -Dave

Jan. 16, 2002

Re: basic structures for async IO in winsock

by lawson_whitney＠juno.com

On Wed, 16 Jan 2002, Martin Wilck wrote: > > Patch: async-winsock.diff > Applies: CVS 2002-01-15 > > Introduce data structures and basic functions for asynchronous > Winsock2 operations. > > ChangeLog: > > include/winsock2.h: Fix LPWSAOVERLAPPED declaration. > dlls/winsock/socket.c: Add basic data strutures & functions for overlapped IO > in Winsock. > Juno 4 without the async winsock patches.

Jan. 16, 2002

16 bit menus

by lawson_whitney＠juno.com

Good day! Last time but one I tested juno 1.49 for regressions in 16 bit comms, it downloaded a new list of access numbers. Next it presented me with the attached menu (well, I attached a trace of it making the menu), which it expects me to work through and select a new number. Unfortunately, the menu seems to be either 0 or 1 pixels high and I can't find any of the controls in there. If somebody can tell me what parameter to what function provokes this, maybe I can work out a way to fix it. Of course, anybody who knows what [s]he is doing with menus is welcome to fix it, too. I have used this menu with this app, but not for perhaps a year. Lawson

Jan. 16, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

On Wed, 16 Jan 2002, Martin Wilck wrote: > > This patch needs testing yet - I am sending it for people to > review and point out errors right from the start. > > Currently I only verified that it compiles. > > ChangeLog: > implement overlapped recv(), much like overlapped IO in > files/file.c. > make WS2_32 WSARecvFrom() the "working" function, > all others are wrappers only. > implement WSAGetOverlappedResult(). > > NOTE: My patches submitted yesterday and today (16/01) to wine-patches > are necessary for this one to work. CVS base version is 2002-01-15. > > Martin > > These 2 +winsock traces are from juno 4 (socks.gz) and juno 2 (winsock.gz). Seems rather sluggish. I wish I'd run traces without the patch also. Connection is rather tenuous anyway - ppp to a broken-ring net to a router to an ethernet LAN to a proxy server to I'm not sure what kind of link to the internet, but it usually works faster than that. The app reported it failed to get my mail on the first session, but sent 1 letter. At that point I started tracing it and it reported success, but was very sluggish. Maybe you can see something in the traces. I'll try backing out the patches and make another trace or two, I guess. Lawson ---oof---

Jan. 16, 2002

Re: SHGetSpecialFolderLocation function

by juergen.schmied＠debitel.net

> What I've found though with the SHGetSpecialFolderLocation, is that it seems > to me that it is designed to allow the caller to pick an arbitrary value for > the CSIDL, and that this will cause windows to create a new CSIDL. As the > function's implementation currently stands, it has a hard-coded table of > possible CSIDLs, and rejects calls with unknown CSIDLs. This is right. There is a list with valid CSIDL's. These CSIDL's are mapped to a unique value name in the registry. These functions are supposed to fail when called with a CSIDL which is not predefined. (Whats not saying wine knows all CSIDL's). > Has anyone else looked at this function, and does anyone have any comments or > suggestions on ways to address this? I'm thinking that these values probably > need to go into the registry, or something, rather than being stored in the > code... There is only a need to store the values in the registry when the path is different from the default value. If the there are no registry entrys in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\Shell Folders HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\User Shell Folders HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVer sion\Explorer\Sh ell Folders HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVer sion\Explorer\Us er Shell Folders the the default values are used. (Was in w95, nt4 like this. Don't know it its true for w2k since apparently most values are set at installation time and there are more values used than before.) Last but the not least: the current implementation was designed to work without much preset values in the registry to simplify the installation. The implementation should be cleaned up starting with ShGetFolderLocation since this is the common base of SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocationand SHGetSpecialFolderPath and you should have a fallback to deal with a empty registry. (I'm not up to date with the wine installation procedure but the installer would have to put many keys in the registry for a good shell32 konfiguration.) Juergen --- juergen.schmied(a)debitel.net

Jan. 16, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

On Wed, 16 Jan 2002 lawson_whitney(a)juno.com wrote: > > -- > Just to add insult to injury, this letter is by juno version 4 using > winsocks, this patch and the 3 others mentioned above. Had to use patch -l > again. It doesn't constitute a test for asynchronous winsocks, but at least > the patches don't break my mail apps. Maybe. > > Lawson > That seemed awfully slow and sluggish, took about 10 minutes to get back my copy of this letter. Transfer time, I mean, not response time. winsock trace will be along presently. ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

Jan. 16, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

> > This patch needs testing yet - I am sending it for people to > review and point out errors right from the start. > > Currently I only verified that it compiles. > > ChangeLog: > implement overlapped recv(), much like overlapped IO in > files/file.c. > make WS2_32 WSARecvFrom() the "working" function, > all others are wrappers only. > implement WSAGetOverlappedResult(). > > NOTE: My patches submitted yesterday and today (16/01) to wine-patches > are necessary for this one to work. CVS base version is 2002-01-15. > > Martin > > -- Just to add insult to injury, this letter is by juno version 4 using winsocks, this patch and the 3 others mentioned above. Had to use patch -l again. It doesn't constitute a test for asynchronous winsocks, but at least the patches don't break my mail apps. Maybe. Lawson

Jan. 16, 2002

Re: struct async-private - now tested and cleaned up

by lawson_whitney＠juno.com

On 16 Jan 2002, Alexandre Julliard wrote: > The comm.c part doesn't apply, are you sure this is against a clean > CVS? You should probably consider using cvs diff, it helps making > sure you do the diff against the right file. > I admit I had to use -l on it to get it to apply, but I didn't think anything of that at the time. Lawson

Jan. 16, 2002