- Wine-Devel - list.winehq.org

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

Re: A better Beep
by Marcelo Duarte May 17, 2005

May 17, 2005

Whats happens if a program calls bepp with invalid values for dwFreq and dwDur on a linux console? (the programmer thinks that dwFreq and dwDur are ignored by Win95). David Lee Lambert escreveu: >Changelog: > Support beeping with the PC speaker when running from the Linux console > > > >------------------------------------------------------------------------ > >--- dlls/kernel/console.c.v1_39 Fri May 13 15:38:16 2005 >+++ dlls/kernel/console.c Fri May 13 21:02:19 2005 >@@ -193,9 +193,19 @@ > */ > BOOL WINAPI Beep( DWORD dwFreq, DWORD dwDur ) > { >- static const char beep = '\a'; >- /* dwFreq and dwDur are ignored by Win95 */ >- if (isatty(2)) write( 2, &beep, 1 ); >+ if (strcmp(getenv("TERM"),"linux")==0 && isatty(2)) { >+ /* the Linux console supports setting frequency and duration */ >+ char szBeep[50]; >+ snprintf(szBeep,50,"\x1B[10;%d]\x1B[11;%d]\a",(int)dwFreq,(int)dwDur); >+ write( 2, szBeep, strlen(szBeep) ); >+ usleep(dwDur*1000); >+ } else if (isatty(2)) { >+ /* dwFreq and dwDur are ignored by Win95 */ >+ static const char beep = '\a'; >+ write( 2, &beep, 1 ); >+ } else { >+ /* TODO: we could play a .wav file instead... */ >+ } > return TRUE; > } > > >

1 0

exeCryptor
by Kenneth Porter May 17, 2005

May 17, 2005

<http://www.strongbit.com/execryptor.asp> Anyone have experience with this on WINE? Another developer pointed this out to me for use with a Windows binary, and is not releasing Linux betas because there's no native Linux equivalent. (The app works fine native in Linux, but the dev want's to prevent unauthorized use until GA.)

3 4

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink May 17, 2005

May 17, 2005

The user interface is what the user has to do to use the program. This is not supported in Wine. You will find links from winehq to several lists of things that run under Wine. When you attempt to use these lists you will find that many if not most of the programs do not run as is. The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away. Even if he persists there is still the problem of figuring out exactly how to make many if not most of the programs in the will run database work. The public simply won't put up with this. You can't have Wine so that a user must be a priest to load a special dll or to find out what special dll is necessary. Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine. How do you currently make Office or Acrobat work on Wine? To my knowledge there are currently no large or complicated programs that you just load and run under Wine. You must set them all up first. It doesn't make any difference to the user if a program fails because of a sound driver. Waiting for all this to be fixed perfectly means a wait forever and serves no purpose without at least simple instructions on how to use Wine now.

4 4

DirectX and Games
by Ivan Gyurdiev May 16, 2005

May 16, 2005

Out of curiosity, why hasn't Oliver's swapchains and stateblocks patch been merged? I saw that in wine-patches about 10 days ago, but it hasn't been merged, and there's no comments at all. ===== On an unrelated note, what is causing this bug: http://bugs.winehq.org/show_bug.cgi?id=2082 As I understand, this is a regression, since Diablo used to work a long time ago, and then some patch broke it. The bug was opened sometime in March... -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

3 3

Re: edit: no not use LOCAL_*() functions
by Alexandre Julliard May 16, 2005

May 16, 2005

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > @@ -426,19 +425,21 @@ static LRESULT WINAPI EditWndProc_common > { > EDITSTATE *es = (EDITSTATE *)GetWindowLongW( hwnd, 0 ); > LRESULT result = 0; > + STACK16FRAME *stack16; > + HANDLE16 oldDS; > > TRACE("hwnd=%p msg=%x (%s) wparam=%x lparam=%lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wParam, lParam); > > if (!es && msg != WM_NCCREATE) > return DefWindowProcT(hwnd, msg, wParam, lParam, unicode); > - else if (msg == WM_NCCREATE) > - return EDIT_WM_NCCreate(hwnd, (LPCREATESTRUCTW)lParam, unicode); > - else if (msg == WM_DESTROY) > - return EDIT_WM_Destroy(es); > > + if (es && (msg != WM_DESTROY)) EDIT_LockBuffer(es); > + > + /* Make sure DS points to hInstance for 16-bit apps */ > + stack16 = (STACK16FRAME*)MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); > + oldDS = stack16->ds; > + stack16->ds = GetWindowLongPtrW( hwnd, GWLP_HINSTANCE ); It seems dangerous to set DS for the whole window procedure, it will be calling a lot of other functions that may end up depending on DS. It's especially dangerous here since the window instance won't be a valid DS for 32-bit windows. I think you really want to set it only around the Local* calls and restore it as soon as possible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Unknown stab type in crashes
by James Hawkins May 16, 2005

May 16, 2005

Hey, Whenever wine crashes, I get a long stream of err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e Does everyone else get that too? Does anyone have info on this? It's understandable to output an unknown type, but it does make the backtrace pretty much useless. After a couple parts of the bt, the error message files a couple hundred lines, then another couple lines of the bt, so I can't see the whole bt at once. Sometimes parts of the bt are scrolled up past my history limit. I don't mean to complain, but it is hampering debugging a bit. -- James Hawkins

4 6

Re: comctl32: Move TrackMouse handling to MouseMove
by Alexandre Julliard May 16, 2005

May 16, 2005

James Hawkins <truiken(a)gmail.com> writes: > This patch also fixes the WM_LBUTTONUP bug, and the new behavior with > listview is even better. The logic behind this is that we only want > to track the mouse by calling TrackMouse when the mouse moves. What you really want is to only start tracking if it moves by more than a certain amount, which is what LISTVIEW_TrackMouse already tries to do in a very inefficient way. So you should probably move all the logic from LISTVIEW_TrackMouse to the MouseMove handler. -- Alexandre Julliard julliard(a)winehq.org

1 0