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

Re: Abort glyph rendering if everything is clipped
by Warren_Baird＠cimmetry.com 08 Oct '03

08 Oct '03

> It would be better IMO to do that as part of the clip rectangle > calculation a few lines below. Well, it was intended as an optimization - if we move the check down to the "if (flags & (ETO_CLIPPED) ..." clause, we may end up doing a HeapAlloc, and calls to GetGlyphIndices and GetObject that we don't need to do. I'd much rather bail out as soon as we can and avoid doing all of that extra work... Warren

2 1

Build without optimization is broken again
by Pavel Roskin 08 Oct '03

08 Oct '03

Hello! Build without optimization is broken again in CVS: gcc -o wine -Wl,--section-start,.interp=0x3c000100 main.o -L../dlls -lntdll.dll -L../libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port ../dlls/libntdll.dll.so: undefined reference to `SetLastError' ../dlls/libntdll.dll.so: undefined reference to `GetCurrentProcessId' ../dlls/libntdll.dll.so: undefined reference to `GetCurrentThreadId' GetCurrentProcessId() and GetCurrentThreadId() are referenced by dlls/ntdll/virtual.c and dlls/ntdll/server.c respectively because they don't include ntdll_misc.h header that has replacement includes. SetLastError() is used by the set_status() wrapper in dlls/ntdll/heap.c. I believe NtCurrentTeb()->last_error is valid even for gcc x86 builds. At least it's used unconditionally in LdrInitializeThunk(), file dlls/ntdll/loader.c. ChangeLog: * dlls/ntdll/server.c, dlls/ntdll/virtual.c: Include ntdll_misc.h to suppress wrong dependencies when building Wine without optimization. * dlls/ntdll/heap.c: Define set_error unconditionally to eliminate dependency on SetLastError(). -- Regards, Pavel Roskin

1 0

Re: Render strings longer than 128 characters as individual chars
by Warren_Baird＠cimmetry.com 08 Oct '03

08 Oct '03

Thanks for the suggestion, Huw. I'll try applying that xrender patch to our build of X and see if it fixes the problems we were having... > If we really have to have > a workaround in Wine then the string should at least be batched rather > than passed character by character. I agree that this would be better - but using existing code that we know works had a distinct appeal, and in our testing we only came across a *very* few places where this happened, so trying to optimize it seemed like it wasn't worth the effort. Warren

1 0

A link to a article on Wine.
by Hannu Valtonen 08 Oct '03

08 Oct '03

Hello, I noticed a link on LinuxToday to an article on Wine and thought people might be interested. http://insight.zdnet.co.uk/business/0,39020481,39116972,00.htm (Summary) Basically the writer tried to install Paintshop Pro. Couldn't get it to work (InstallShield problem) and was frustrated by that. On the other hand he does recommend CrossOver Office as a polished product for firms and Wine for those who wish to experiment on their own. - Hannu Valtonen Hannu.Valtonen(a)hut.fi

2 1

What does it take to run a third-party DLL under Wine?
by John Conneely 08 Oct '03

08 Oct '03

Hi! I need help determining the feasibility of writing a wrapper around a DLL so that I can call it from a Linux machine, perhaps as a SO. I'm looking for either a member of this list that could contract with us for support, or pointers to a more appropriate place where I can search for such a person. If you're interested in learning more, please read on - otherwise, thanks for your time! The DLL in question is one that interacts with call recording equipment in a telephone switch. Our customer has an incoming call center where they currently use windows machines on the desktops of the telephone agents. They're looking to replace these desktops with Linux machines, and are trying to convert to a 100% non-Microsoft shop. This DLL has five or six function calls that presumably communicates over the network with the switch. My initial thought was that we have three choices of how to architect a solution: 1) Port the code to Linux. I eliminated this as a choice because we don't have the source code for the DLL. 2) Use some kind of RPC mechanism (COBRA, SOAP, etc.) to have the DLL running under windows on a server. This would work in principle, and apparently it is the preferred solution by the maker of the DLL. However, it violates our client's no-Microsoft-code mandate, and our customer has rejected this as a solution. 3) Write a wrapper to use the DLL running under WINE. This is what I am pursuing now. I'm looking for someone who has done #3 for other DLLs, and understands the issues that might come up in getting a third party DLL to run under WINE without active support from the DLL's authors. I myself have used Linux quite extensively but have not had the opportunity to use WINE directly, so we will likely need some help in setting up our WINE environment. We've got funding to pursue this, so if you can show me that you've done something like this before, we will pay you to first do a feasibility analysis on the DLL in question, and then implement it. Thanks! John

3 3

Re: Move actual code out of assert statements
by Warren_Baird＠cimmetry.com 08 Oct '03

08 Oct '03

> The indentation is messed up. You should set your editor tab width to > 8 instead of 4. My apologies --- our internal coding standard has tabs set at 4 spaces - and I haven't figured out how to tell xemacs to use tabs of 8 spaces in some directories, and 4 spaces in others... I thought I had fixed any indentation issues in the patches I was submitting - guess I missed this one. I'll resubmit shortly... Warren

1 0

Wineconf survey - interim results - call for more votes
by Jeremy White 08 Oct '03

08 Oct '03

Hi folks, I've posted interim results at http://www.winehq.org/wineconf/midresults.html It looks like St. Paul and Munich are the leading contenders, but I'm concerned that we have a fairly modest turnout (although I and several others at CodeWeavers haven't voted yet). I haven't done any weighting yet, and I'm actually worried that my comments on weighting may have discouraged folks from responding. My plan was to only modestly increase the pull of major contributors; even votes from plebes like me will have value. So, again, if you would come to Wineconf, and haven't done so yet, please pop over to http://www.winehq.org/wineconf/ I'll call it final on Friday and tally results. Cheers, Jer

1 0

alsa, arts, etc
by dwillis＠stx.rr.com 08 Oct '03

08 Oct '03

how can i get alsa, arts, etc for audio instead of oss? i'm using wine for cooledit96 and the 3 second delay for oss emulation is quite annoying, but i'm still very happy to be using cooledit96 under linux. i'm using wine version 20030813. thanks, dave

2 2

Re: Render strings longer than 128 characters as individual chars
by Huw D M Davies 08 Oct '03

08 Oct '03

On Tue, Oct 07, 2003 at 01:03:08PM -0400, Warren_Baird(a)cimmetry.com wrote: > > > > (See attached file: patch_xrender_long_string.txt) This is most likely due to a buggy version of libxrender which Keith fixed with the attached patch to the XFree86 cvs. I'd suggest upgrading to a newer version of the library. If we really have to have a workaround in Wine then the string should at least be batched rather than passed character by character. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: Protected mode interrupt problem
by Jukka Heinonen 08 Oct '03

08 Oct '03

Mike McCormack wrote: > Two 16bit programs launch, one after the other. Each program hooks INT > 0, however since our interrupt tables are global to all tasks, the > second task retrieves the interrupt vector that the first task set. > > The first task exits, and restores the original INT 0 vector. When the > second task exits, tries to restore the INT 0 vector set by the first > task, which now has an invalid selector, so it crashes. > > After a bit of discussion and writing a test program, we discovered that > it appears that some interrupt vectors are task local, and some are > global. The local ones appear to be stored in the TDB (task descriptor > block), in offsets 0x26 - 0x4a. > > The attached patch fixes this, though we're not sure that it is correct > for DOS programs. Well, I don't know much about the relation between Win16 tasks and DOS. If this is how interrupt vectors are handled under Win16 then I guess the basic idea in the patch is correct. However, I can't see why this would cause a crash because as far as I know, int 0 vector is never called by Wine. It doesn't really matter but I'm just curious... (Perhaps they handle int 0 as a call chain?) Anyway, this patch fails to initialize the vectors so any attempt to use them causes a crash. These vectors are not currently used by Wine (except 0x3e) so this is not yet a problem but I would really like to see this patch changed so that those vectors are properly initialized (possibly lazily) at program startup and when new task is created (are they copied from another task or reset to default values?). And, I don't think TASK_GetCurrent() should be called from winedos and I thought use of WINE_PACKED was unnecessary and deprecated. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 2