May 2005 - Wine-Devel - list.winehq.org

Detecting ulimit problem
by Eric Frias May 19, 2005

May 19, 2005

I just ran into bug 2609: http://bugs.winehq.org/show_bug.cgi?id=2609 which is that wine fails to initialize when the user has a ulimit for virtual memory (address space) set to less than around 1300MB. This is something wine could test for and issue a warning. I know this isn't technically a problem with wine, but it's pretty unusual for an application to require that much address space. A user might not even realize they have a limit set if they haven't encountered problems with other large applications. It looks like I'm at least the third person to encounter this, and a hint to look at ulimit instead of other things (like the overcommit_memory setting) would've saved me some time. Something like: struct rlimit address_limits; int required_address_space = 1024 * 1024 * 1400; /* 1400M */ getrlimit(RLIMIT_AS, &address_limits); if (address_limits.rlim_max < required_address_space) WINE_WARN("Your virtual memory limit is set to %dk, which will\nprobably prevent wine from loading correctly. If you get an error,\nincrease the limit with 'ulimit -v' to at least %dk.\n", address_limits.rlim_max / 1024, required_address_space / 1024); I don't know how to determine the exact amount of address space wine requires, since it seems to vary somewhat with the application -- 1300M is enough for notepad, our own winelib app requires at least 1375M. Would a warning like this be appropriate? Eric

1 0

Re: Added the feature to change row height in owner draw controls.
by Dimitrie Paun May 19, 2005

May 19, 2005

> Added the feature to change row height in owner draw controls. The indentation looks a bit funky on this one -- can you please use 4-space indentation? -- Dimi.

2 2

Re: list: make LIST_FOR_EACH_ENTRY look more like a for loop
by Alexandre Julliard May 19, 2005

May 19, 2005

Dimi Paun <dimi(a)lattica.com> writes: > I've always been a bit confused about the parameters to the > list macros. If you don't use them much (which I didn't) it's > hard to remember them. I think it would be best if we are > consistent with other for loops out there. I think they are perfectly consistent as they are. The common form of a for loop is something like 'for cursor in list', that's also what LIST_FOR_EACH does, so it makes sense to have LIST_FOR_EACH_ENTRY do the same. The extra 2 parameters are implementation details about the object structure, that are just fine at the end. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: list: make LIST_FOR_EACH_ENTRY look more like a for loop
by Robert Shearman May 19, 2005

May 19, 2005

Dimi Paun wrote: >I've always been a bit confused about the parameters to the >list macros. If you don't use them much (which I didn't) it's >hard to remember them. I think it would be best if we are >consistent with other for loops out there. > >ChangeLog > Change the parameter order for LIST_FOR_EACH_ENTRY() > to more closely match the for loop. > > > > >------------------------------------------------------------------------ > >Index: ./include/wine/list.h >=================================================================== >RCS file: /var/cvs/wine/include/wine/list.h,v >retrieving revision 1.6 >diff -u -p -r1.6 list.h >--- ./include/wine/list.h 18 May 2005 13:24:46 -0000 1.6 >+++ ./include/wine/list.h 19 May 2005 12:19:33 -0000 >@@ -55,7 +55,7 @@ struct list > * And to iterate over it: > * > * struct gadget *gadget; >- * LIST_FOR_EACH_ENTRY( gadget, &global_gadgets, struct gadget, entry ) >+ * LIST_FOR_EACH_ENTRY( struct gadget, entry, &global_gadgets, gadget ) > * { > * ... > * } > > I don't think this makes any more sense with your patch than before. LIST_FOR_EACH_ENTRY is different to a for statement because LIST_FOR_EACH_ENTRY doesn't declare the start condition, end condition and iterator because these are defined by the macro itself. The parameters are really just defining what you are iterating on and what you are using. Rob

1 0

Re: Corrected the priority of operators for LISTVIEW_GetNextItem function.
by taro-x＠justsystem.co.jp May 19, 2005

May 19, 2005

2005-05-19 Kouji Sasaki <taro-x(a)justsystem.co.jp> > > Changelog: > > > > * dlls/comctl32/listview.c > > > > Corrected the priority of operators for LISTVIEW_GetNextItem function. > > > --- dlls/comctl32/listview.c 2005-04-14 22:58:24.000000000 +0900 > > +++ dlls/comctl32/listview.c 2005-05-16 11:29:08.003084512 +0900 > > @@ -5665,7 +5665,7 @@ > > * so it's worth optimizing */ > > if (uFlags & LVNI_FOCUSED) > > { > > - if (!(LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask) return -1; > > + if (!((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask)) return -1; > > Wouldn't it be more readable and less confusing in the below form? > > if ((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) != uMask) return -1; > > > -- > Dmitry. > I will send the modified patch, as changing the patch accordingly will make the source much easier to read. Changelog: * dlls/comctl32/listview.c Corrected the priority of operators for LISTVIEW_GetNextItem function. -- Justsystem Corporation <taro-x(a)justsystem.co.jp>

1 0

Re: Added the callback item processing for LISTVIEW_EndEditLabelT function.
by Dimitrie Paun May 19, 2005

May 19, 2005

> Added the callback item processing for LISTVIEW_EndEditLabelT function. I think this would be a bit more explicit and correct (is_textW() returns false if pszText == NULL) if the test is the other way around: + if (lpItem && lpItem->hdr.pszText == LPSTR_TEXTCALLBACKW) + { + LISTVIEW_InvalidateItem(infoPtr, infoPtr->nEditLabelItem); + } + else + { + ZeroMemory(&dispInfo, sizeof(dispInfo)); + dispInfo.item.mask = LVIF_TEXT; + dispInfo.item.iItem = infoPtr->nEditLabelItem; + dispInfo.item.iSubItem = 0; + dispInfo.item.pszText = pszText; + dispInfo.item.cchTextMax = textlenT(pszText, isW); + return LISTVIEW_SetItemT(infoPtr, &dispInfo.item, isW); + } -- Dimi.

2 1

Re: Implement NtQuerySystemInformation(SystemTimeOfDayInformation)
by Rein Klazes May 19, 2005

May 19, 2005

On Tue, 17 May 2005 23:06:51 +0200, you wrote: > + RtlSystemTimeToLocalTime(&sys_time, &local_time); > + /* liExpTimeZoneBias is not the same as tzi.Bias since it takes > + * disabled DST correction into account (tested on WinXP). */ > + local_diff.QuadPart = sys_time.QuadPart - local_time.QuadPart; You mean the "Automatically adjust clock for daylight saving"? Wine does not follow this silly flag and at a couple of places it depends on it. I doubt whether it should. > + > + sti->liKeBootTime = NTDLL_BootTime; > + sti->liKeSystemTime = sys_time; > + sti->liExpTimeZoneBias = local_diff; > + sti->uCurrentTimeZoneId = RtlQueryTimeZoneInformation(&tzi); This does not look correct. AFAIK RtlQueryTimeZoneInformation returns an NT-status code, 0 is no success, otherwise it is an error code. Have a look at GetTimeZoneInformation how to compute a TimeZoneId. Rein.

2 3

Re: [crypt32] take 3: CryptProtectData/CryptUnprotectData helper functions
by Mike McCormack May 18, 2005

May 18, 2005

Kees Cook wrote: > Corrected for MESSAGE() use and a botch of wine_dbg_sprintf usage. Julliard won't commit dead code, so you have to make sure that each function that you send is used by something else. How about sending a patch implementing CryptProtectData()? Mike

1 0

Re: [crypt32] CryptProtectData/CryptUnprotectData helper functions
by Alexandre Julliard May 18, 2005

May 18, 2005

Kees Cook <kees(a)outflux.net> writes: > +static int > +hexprint(const char *s, unsigned char *p, int n) > +{ > + char report[80]; > + int r=-1; > + snprintf(report,16,"%14s:", s); > + while (--n >= 0) > + { > + if (r++ % 20 == 19) > + { > + wine_dbg_printf("%s\n",report); > + snprintf(report,16,"%14s ", ""); > + } > + sprintf(report+strlen(report)," %02x", *p++); > + } > + wine_dbg_printf("%s\n",report); You should use wine_dbg_sprintf here and return a string. > +static > +void serialize_dword(DWORD value,BYTE ** ptr) > +{ > + /*TRACE("called\n");*/ > + > + *((DWORD*)*ptr)=value; > + *ptr+=sizeof(DWORD); This (and other similar things later on) isn't safe for CPUs that don't allow unaligned accesses, you have to use memcpy instead. > +static > +BOOL fill_protect_data(struct protect_data_t * pInfo, LPCWSTR szDataDescr, > + HCRYPTPROV hProv) > +{ > + DWORD dwStrLen; > + > + TRACE("called\n"); > + > + if (!pInfo) return FALSE; > + > + dwStrLen=lstrlenW(szDataDescr); > + > + memset(pInfo,0,sizeof(*pInfo)); > + > + pInfo->count0=0x0001; > + > + pInfo->info0.cbData=strlen(crypt_magic_str)+1; > + pInfo->info0.pbData=strdup(crypt_magic_str); You don't want to use strdup, you should use HeapAlloc and friends (especially since you use HeapFree later on). > +static void > +crypt_report_func_input(DATA_BLOB* pDataIn, > + DATA_BLOB* pOptionalEntropy, > + CRYPTPROTECT_PROMPTSTRUCT* pPromptStruct, > + DWORD dwFlags) > +{ > + wine_dbg_printf("\tpPromptStruct: 0x%x\n",(unsigned int)pPromptStruct); > + if (pPromptStruct) > + { > + wine_dbg_printf("\t\tcbSize: 0x%x\n",(unsigned int)pPromptStruct->cbSize); > + wine_dbg_printf("\t\tdwPromptFlags: 0x%x\n",(unsigned int)pPromptStruct->dwPromptFlags); > + wine_dbg_printf("\t\thwndApp: 0x%x\n",(unsigned int)pPromptStruct->hwndApp); > + wine_dbg_printf("\t\tszPrompt: 0x%x %s\n", > + (unsigned int)pPromptStruct->szPrompt, > + pPromptStruct->szPrompt ? debugstr_w(pPromptStruct->szPrompt) > + : ""); > + } > + wine_dbg_printf("\tdwFlags: 0x%04x\n",(unsigned int)dwFlags); > + wine_dbg_printf("\tpDataIn->cbData: %u\n",(unsigned int)pDataIn->cbData); > + wine_dbg_printf("\tpDataIn->pbData: 0x%x\n",(unsigned int)pDataIn->pbData); > + hexprint("pbData", pDataIn->pbData, pDataIn->cbData); > + if (pOptionalEntropy) > + { > + wine_dbg_printf("\tpOptionalEntropy->cbData: %u\n",(unsigned int)pOptionalEntropy->cbData); > + wine_dbg_printf("\tpOptionalEntropy->pbData: 0x%x\n",(unsigned int)pOptionalEntropy->pbData); > + hexprint("pbData", pOptionalEntropy->pbData, pOptionalEntropy->cbData); > + wine_dbg_printf("\t\t%s\n",debugstr_an(pOptionalEntropy->pbData,pOptionalEntropy->cbData)); > + } > + > +} > + > +static void > +announce_bad_opaque_data() > +{ > + wine_dbg_printf("CryptUnprotectData received the following pDataIn DATA_BLOB that seems to\n"); > + wine_dbg_printf("have NOT been generated by Wine:\n"); > +} You should use the TRACE/FIXME macros here, not raw wine_dbg_printf. -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: [crypt32] CryptProtectData/CryptUnprotectData helper functions
by Kees Cook May 18, 2005

May 18, 2005

On Wed, May 18, 2005 at 12:29:58PM -0700, Kees Cook wrote: > Take two. Ignore... this patch is broken, and I need to do an update of wine_dbg_printf() -> MESSAGE() -- Kees Cook @outflux.net

1 0

Re: [wine] Re: A better Beep
by Marcelo Duarte May 18, 2005

May 18, 2005

David Lee Lambert escreveu: >On Tue, May 17, 2005 at 10:43:25AM -0300, Marcelo Duarte wrote: > > >>Whats happens if a program calls bepp with invalid values for dwFreq and >>dwDur on a linux console? >> >> > >The bell becomes inaudible until reset by another terminal-control >sequence. However, the special value (duration=-1) does not have the >same semantics; it's simply ignored. > >On my box that has a PC speaker, the bell is silent when any of the >following are true: > >freq < 21 >dur == 0 >dur > 1999 > >I can't hear any tones above 12000 Hz or so, but I'm not sure whether >that's my hearing, the speaker-hardware, or the kernel's decision. > >Should I add range-checks on frequency and duration? > > > >>(the programmer thinks that dwFreq and dwDur are ignored by Win95). >> >> > >That's what the API documentation says. Are they used on WinXP or Win2k? > > > If you have programs to test, send me.

1 0

MSN Webcam
by Joaquín Fernández May 18, 2005

May 18, 2005

hmmmm... can you use a webcam in msn under wine???? If yes, can you explain to me how to do it? I was not able to run msn messenger in wine. Regards Joaquín -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

2 1

Re: list.h: document the more convenient iteration method
by Dimi Paun May 18, 2005

May 18, 2005

On Wed, 2005-05-18 at 08:01 -0400, Dimi Paun wrote: > * struct list *cursor; > - * LIST_FOR_EACH( cursor, &global_gadgets ) > + * LIST_FOR_EACH_ENTRY( cursor, &global_gadgets, struct gadget *, > gadget ) > * { Looking at this, why do we need cursor at all for the LIST_FOR_EACH_ENTRY? Also the type and iteration var should come first, to be simiar for loops in pretty much any language out there. I think it should just be: LIST_FOR_EACH_ENTRY( struct gadget *, gadget, &global_gadgets ) Ah, I see now the problem. We would need to end it with LIST_END instead of just doing {...}. Not such a big deal, we do the same for server requests too :) But I can see why we would like to keep cursor. If so, it should come at the end: LIST_FOR_EACH_ENTRY(struct gadget *,gadget,&global_gadgets,cursor) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Small cleanup in list handling
by Robert Shearman May 18, 2005

May 18, 2005

Dimi Paun wrote: >Index: dlls/ntdll/exception.c >=================================================================== >RCS file: /var/cvs/wine/dlls/ntdll/exception.c,v >retrieving revision 1.75 >diff -u -p -r1.75 exception.c >--- dlls/ntdll/exception.c 13 May 2005 13:56:47 -0000 1.75 >+++ dlls/ntdll/exception.c 13 May 2005 19:01:31 -0000 >@@ -480,7 +480,8 @@ ULONG WINAPI RtlRemoveVectoredExceptionH > RtlEnterCriticalSection( &vectored_handlers_section ); > LIST_FOR_EACH( ptr, &vectored_handlers ) > { >- if (ptr == &((VECTORED_HANDLER *)handler)->entry) >+ VECTORED_HANDLER *curr_handler = LIST_ENTRY( ptr, VECTORED_HANDLER, entry ); >+ if (curr_handler == handler) > { > list_remove( ptr ); > ret = TRUE; > > This patch has already been committed, but for future reference code of this form: LIST_FOR_EACH( cursor, list) { TYPE list_entry = LIST_ENTRY( cursor, TYPE, entry ); ... Can be replaced by the following for IMHO, slightly more readable code: LIST_FOR_EACH_ENTRY( list_entry, list, TYPE, entry) { ... Rob

2 1

Re: MSN Webcam
by Maarten Lankhorst May 18, 2005

May 18, 2005

MediaHost (TM) wrote: > Looks interesting! Any idea, when your patches get committed into the > "official" releases? > >> Maarten Lankhorst wrote: >> >>> Status: Nearly complete, need testers. >>> >>> http://wiki.winehq.org/MSN_Messenger_webcam_support >>> >>> You need the native quartz dll, which get installed with internet >>> explorer, as the builtin quartz doesn't work properly when changing >>> media format on initialisation. >> >> Possibly a problem with the code I wrote. Can you provide more >> details on this? >> >>> IFilterGraph Reconnect isn't implemented, and for some reason *looks >>> strangely at Robert* instead of a FIXME() there's a TRACE telling it >>> is a stub... >> >> I didn't write any of the IFilterGraph implementation, but you are >> right that it is crazy. >> >> Rob >> Writing some final bugfixes at the moment, so I think a matter of days before it'll be done in a state that julliard might commit.. There were 2 small reasons why builtin quartz wasn't working 1. if format changed, it would need to reconnect with new size (Quartz, submitted a patch) 2. if format wasn't changed, I used my own optimized code, that wrote 960 bytes to a wrong place, so it crashed. (Totally my fault) btw, nice name and signature...

1 0

Re: [WINEDOCS] Add missing tag
by Dimi Paun May 18, 2005

May 18, 2005

On Wed, 2005-05-18 at 10:37 +0200, Francois Gouget wrote: > Add missing <qandaentry> tag. Oops, too late, I've already committed the fix last night. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: comctl32: Move mouse tracking to MouseMove [RESEND]
by Dimi Paun May 18, 2005

May 18, 2005

On Wed, 2005-05-18 at 00:31 -0500, James Hawkins wrote: > + LVHITTESTINFO lvHitTestInfo; > + INT nItem; > + > + if (infoPtr->bLButtonDown) > + { > + lvHitTestInfo.pt = infoPtr->ptClickPos; > + nItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, > TRUE); > + > + if (DragDetect(infoPtr->hwndSelf, infoPtr->ptClickPos)) > + { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); Why not move the lvHitTestInfo and nItem into the inner scope: if (infoPtr->bLButtonDown && DragDetect(infoPtr->hwndSelf, infoPtr->ptClickPos)) { LVHITTESTINFO lvHitTestInfo; NMLISTVIEW nmlv; ZeroMemory(&nmlv, sizeof(nmlv)); lvHitTestInfo.pt = infoPtr->ptClickPos; nmlv.iItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, TRUE); .... } -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

MSN Webcam
by Maarten Lankhorst May 18, 2005

May 18, 2005

Status: Nearly complete, need testers. http://wiki.winehq.org/MSN_Messenger_webcam_support You need the native quartz dll, which get installed with internet explorer, as the builtin quartz doesn't work properly when changing media format on initialisation. IFilterGraph Reconnect isn't implemented, and for some reason *looks strangely at Robert* instead of a FIXME() there's a TRACE telling it is a stub...

2 1

Re: [crypt32] implementation of CryptProtectData/CryptUnprotectData
by Mike McCormack May 18, 2005

May 18, 2005

Kees Cook wrote: > Hi, I'm back again. :) This implements the crypt32 functions > CryptProtectData and CryptUnprotectData, using a best-guess at the true > Windows opaque data format and encryption methods. It attempts to > follow the "details" in the MSDN article that described > CryptProtectData. > > Please let me know how this all looks. Hopefully I've got it mostly > right this time. If there is a more sane way to handle the structure > serialization/unserialization, I'm all ears. > > (Anyone paying really close attention will note that I uncovered some > crash bugs in rsaenh as a result of my crypt32 test cases. Make sure > you've done a "cvs update" to catch those changes before running them.) > > ChangeLog: > Implements a best-guess of CryptProtectData/CryptUnprotectData. Hi Kees, Wow. That's alot of work :) It's usually easier to review these things in smaller chunks. An easy way to do that is to submit header changes first, then stub functions, implementation of each function and a test program, all as seperate patches. A further way for your patch would be to seperate CryptProtectData and CryptUnprotectData data into to two seperate patches, though I understand they are dependent on each other to some extent. This patch looks OK to me at a quick glance, but if it's not applied, please consider breaking it up. At least that way, you'll have less to submit next time round. Mike

3 2

Re: winecfg: Add handling for drive options
by Mike McCormack May 18, 2005

May 18, 2005

James Hawkins wrote: > case WM_COMMAND: > - if (HIWORD(wParam) == EN_CHANGE) > + switch (HIWORD(wParam)) > { I don't know if it's just my opinion, but case statements within case statements make the code more difficult to read. Would you consider creating a new function instead? eg. case WM_COMMAND: OnCommand( dialog, HIWORD(wParam), LOWORD(wParam) ); break; Mike

1 0

Re: comctl32: Move mouse tracking to MouseMove
by Dimi Paun May 18, 2005

May 18, 2005

On Tue, 2005-05-17 at 23:18 -0500, James Hawkins wrote: > Changelog > * Store the click point in LISTVIEW_INFO. > * Move mouse tracking to MouseMove. > * Use DragDetect instead of TrackMouse. > * Remove the unused TrackMouse function. I think you've sent the wrong patch... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Corrected the priority of operators for LISTVIEW_GetNextItem function.
by Dmitry Timoshkov May 18, 2005

May 18, 2005

<taro-x(a)justsystem.co.jp> wrote: > Changelog: > > * dlls/comctl32/listview.c > > Corrected the priority of operators for LISTVIEW_GetNextItem function. > --- dlls/comctl32/listview.c 2005-04-14 22:58:24.000000000 +0900 > +++ dlls/comctl32/listview.c 2005-05-16 11:29:08.003084512 +0900 > @@ -5665,7 +5665,7 @@ > * so it's worth optimizing */ > if (uFlags & LVNI_FOCUSED) > { > - if (!(LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask) return -1; > + if (!((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask)) return -1; Wouldn't it be more readable and less confusing in the below form? if ((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) != uMask) return -1; -- Dmitry.

1 0

Re: storage32.c fix for big endian arch
by Phil Krylov May 17, 2005

May 17, 2005

Please disregard, Pierre d'Herbemont already sent the same few hours before :) -- Ph. On Tue, 17 May 2005 21:41:41 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > ChangeLog: > > Fixed storage32.c compilation in big endian architectures. > > Patch: > > Index: dlls/ole32/storage32.c > =================================================================== > RCS file: /home/wine/wine/dlls/ole32/storage32.c,v > retrieving revision 1.87 > diff -p -u -r1.87 storage32.c > --- dlls/ole32/storage32.c 14 May 2005 11:06:44 -0000 1.87 > +++ dlls/ole32/storage32.c 17 May 2005 17:20:06 -0000 > @@ -4130,8 +4130,8 @@ void StorageUtl_ReadULargeInteger(const > ULARGE_INTEGER tmp; > > memcpy(&tmp, buffer + offset, sizeof(ULARGE_INTEGER)); > - value->LowPart = htole32(tmp.HighPart); > - value->HighPart = htole32(tmp.LowPart); > + value->u.LowPart = htole32(tmp.u.HighPart); > + value->u.HighPart = htole32(tmp.u.LowPart); > #else > memcpy(value, buffer + offset, sizeof(ULARGE_INTEGER)); > #endif > @@ -4143,8 +4143,8 @@ void StorageUtl_WriteULargeInteger(BYTE* > #ifdef WORDS_BIGENDIAN > ULARGE_INTEGER tmp; > > - tmp.LowPart = htole32(value->HighPart); > - tmp.HighPart = htole32(value->LowPart); > + tmp.u.LowPart = htole32(value->u.HighPart); > + tmp.u.HighPart = htole32(value->u.LowPart); > memcpy(buffer + offset, &tmp, sizeof(ULARGE_INTEGER)); > #else > memcpy(buffer + offset, value, sizeof(ULARGE_INTEGER)); > >

1 0

[Fwd: Relationship between Wine and the proprietary versions.]
by Dimi Paun May 17, 2005

May 17, 2005

Hi folks, I've got this request on wine-faq list (deleted the name, don't know if they want to be on wine-devel). Anyone care to write a small blurb about this? -------- Forwarded Message -------- From: XXXXX To: wine-faq(a)winehq.org Subject: Relationship between Wine and the proprietary versions. Date: Mon, 16 May 2005 21:45:11 +0200 Hi Seing Wine, Crossoveroffice and Cedega, i was wondering about the relationship between the projects. I find the concepts they are pursueing important, but i don't like their licenses. I would like Wine to be all that, so i would rather give my support to Wine than to the proprietairy projects. That is not a question of money, but out of licensing issues. So i was wondering if you could explain that in the FAQ also? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

3 4

Wiki
by Robert van Herk May 17, 2005

May 17, 2005

Just wanted to say, that the wiki is great! It makes it much easier to pick a project to work on. Robert

1 0