MAP_ANON support on HPUX

Hi All, I've just discovered that HP-UX's mmap implementation doesn't define MAP_ANON, it only defines MAP_ANONYMOUS. linux defined both, as does solaris (and solaris's manpage actually states that MAP_ANON is deprecated), but MacOS X seems to only define MAP_ANON MAP_ANON is only used in two

Re: -fPIC on link line in winegcc for HPUX

Alexandre Julliard <[EMAIL PROTECTED]> wrote on 10/18/2004 03:11:30 PM: > It's probably better to do that at the configure level by adding it to > LDDLLFLAGS in the case that needs it. Ok, that makes sense - I didn't realize we already had a hook directly from configure into winegcc. I'll just s

Re: -fPIC on link line in winegcc for HPUX

Alexandre Julliard <[EMAIL PROTECTED]> wrote on 10/15/2004 12:03:53 AM: > Actually it could be argued that winegcc should add -fPIC itself if > it's needed for linking, users shouldn't have to worry about that. That makes a lot of sense - I'll mod the patch to do that... Should I make it platfo

RE: .so dependancies in winegcc

Pierre d'Herbemont <[EMAIL PROTECTED]> wrote on 10/10/2004 01:50:39 PM: > Warren, > > On Mac OS X/Darwin .so and .dylib extensions are both used. In fact > .dylib extension is used for dynamic libraries (libwine*.dylib) whereas > dll.so and exe.so extensions are used for the dlls and the exe. S

-fPIC on link line in winegcc for HPUX

Hi all, Another change I had to make for HPUX that I'm not 100% sure about: The HPUX linker gets quite unhappy unless the gcc link line inside of winegcc is fed -fPIC. The problem is that the collect2 phase builds it's own temporary object file that gets included in the final link, and if tha

.so dependancies in winegcc

Hi all, I'm still working on getting wine going on hpux, and I thought I should submit patches for more of the changes I've made. There were a couple of places in winegcc where there were some assumptions made about .so being the shared library extension and .exe.so being the executable suffix

Re: Getting winebuild to work on HP-UX

(BTW, apologies for the Firewall/CSI thing in my previous message's "From:" line - they've been mucking about with our external mail server, and it messed something up - Hope people didn't get bounces if they tried replying directly - hopefully it'll be fixed for this message.) Alexandre Jullia

autoconf issues on HP-UX

Hi all, I'm in the process of trying to get winelib working on an HP-UX / PA-RISC machine. The first issue I've come across is related to autoconf, and I'm afraid I'm far from an autoconf guru, so I wanted to post my proposed solution here before submitting a patch. The problem is that the

Re: Abort glyph rendering if everything is clipped

> That looks better yes; it's still a bit complex IMO, but I'm not sure > it's possible to do much better with that glyph index thing. Still I'm > wondering if you shouldn't do the IsRectEmpty check after the LPtoDP > and coordinates swap. It looks to me like LPtoDP is just doing a linear trans

Re: Byteswapping

> The best is to use the Rtl*ByteSwap functions from winternl.h. That is certainly the best solution --- I hadn't noticed that those had been added... I'll try redoing our swapping code with them and make sure it all works... Warren

Re: Abort glyph rendering if everything is clipped

> But then you are doing extra work for the "normal" case, and you are > also making the code less readable; not a good trade-off IMO. Well --- trading a memory allocation for an extra comparision instruction makes it a bit trickier to decide, but I take your point. > You > could always move

Byteswapping

Hi all, There are some changes I'd like to submit as patches, but I'm not sure the best way to go about it. We need to add some byteswapping code in a few places to make things happier on big-endian machines. The problem is that the byteswap macros only exist inside wine/tools/wrc right now -

Re: Render strings longer than 128 characters as individual chars

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 th

Re: Abort glyph rendering if everything is clipped

> 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

Re: Move actual code out of assert statements

> 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