The "exec shield" workaround (loader/main.c, libs/wine/port.c) has a
side-effect of leaving a several thousand byte area of memory allocated just
after the reserved pe_area. Under Windows, it is possible to fairly reliably
map files or allocate memory explicitly using a fixed address of 0x10
Chris Morgan wrote:
I did export WINELOADER=`which wine` and it set it to
/usr/local/bin/wine I'll check my machine to ensure that I don't have
multiple copies of the wine or winedbg binaries.
Note that I am getting debug information from wine dlls now, I do not if
I don't set the WINELOADER e
I did export WINELOADER=`which wine` and it set it to
/usr/local/bin/wine I'll check my machine to ensure that
I don't have multiple copies of the wine or winedbg
binaries.
Note that I am getting debug information from wine dlls
now, I do not if I don't set the WINELOADER environment
variabl
Chris Morgan wrote:
Should winedbg be able to load symbols up for non-wine libraries? After the
export WINELOADER idea I've got wine symbols but I'm still trying to debug a
bizzare crash in winejack where I get:
it should
it seems more to me that the wine exec that winedbg is looking at is not
On December 17, 2003 07:57 am, Chris Morgan wrote:
> >I don't like the idea; I much prefer the idea of copying
> >them from somewhere
> >in /etc, as redhat does. The default config file in /etc
> >can then be
> >modified so that it matches the distribution (redhat have
> >their cd at
> >/mnt/cdrom
> Trading off configurability with usability seems fine to
> me.
We aren't as one can tweak things with winecfg if he wants/needs to
> The goal is to solve both
> the lack of config files for binary installs, fixed by the
> patches that Che has in his rpm package and Marcus has for
> Suse, an
Trading off configurability with usability seems fine to
me. I doubt you'd hear much complaining about the default
configuration not being correct and users wanting to edit
it. In either case if the same can be accomplished
without including the config files in the binary then that
of course
Title: Re: Wine Status Page Pre-1
> 3) Send to Brian V for WWN coverage :) (Brian if you want you can get a
> early start)
Hm. 1.7 meters of snow this week at Steamboat and I have the next three days
off. I'm guessing I won't have much done until Monday.
---
Brian Vincent
>The less modification to the install process the better.
>If there was a single location the files could be
>installed to that would work for all distros I think this
>is the route to head in.
You can install the files anywhere, as long as the location isn't already used
for something else, /e
> Read documentation/PACKAGING, I had it added to CVS with most ideas already
> inside on Jun 27, 1999.
I've read this. I also had a look at the recording of your speech about wine
packaging at wineconf 2002.
I've followed the indications of documentation/PACKAGING at lines 385-404,
mainly for usab
I don't like the idea; I much prefer the idea of copying
them from somewhere
in /etc, as redhat does. The default config file in /etc
can then be
modified so that it matches the distribution (redhat have
their cd at
/mnt/cdrom) and it can be modified by the sysadmin
The less modification to
Hi,
Please excuse me for bringing this question here. I'm not a developer. I
have asked this in a couple of different forums but to date have received no
answers. I will copy a message sent earlier this week to Wine-Users and hope
for some insights on how to handle it.
I have done some Googl
On December 16, 2003 06:39 pm, Chris Morgan wrote:
> I was chatting with Rudolf Kastl(che on #winehq) and he was mentioning the
> things that he was doing for the rpm package. One of the patches he
> applies to wine prior to packaging it is a patch that creates local user
> config files if they do
On Wed, Dec 17, 2003 at 10:51:42AM +0100, Ivan Leo Murray-Smith wrote:
> >I was wondering if it would make more sense during the compile process to take
> >the default configuration files, config, system.reg, user.reg and userdef.reg
> >and convert these to binary form and compile them into the w
"Mike Hearn" <[EMAIL PROTECTED]> wrote:
> Isn't this the same bug that kills us in gaming, ie we create unmanaged
> windows for fullscreen and X finds it hard to handle?
It must be the same bug, if the full screen window was really created
as a not managed one. Aric, could you confirm that?
> If
Yes i do believe this is the same bug.
humm, i will investigate more about full screen windows and X although i
am no expert with the x level windows in wine.
-aric
Mike Hearn wrote:
On Wed, 2003-12-17 at 03:15, Dmitry Timoshkov wrote:
That sounds like a bug either in Window Manager you are us
> If wine-c is stored uncompressed, it's easier for a site admin to modify
> it for all its users.
True, but this shouldn't be necessary. Also any global configuration should be
done via winecfg.
> Also, there are a couple places in Wine which are dependant on how the
> underlying distribution is s
Le mer 17/12/2003 Ã 05:52, Ivan Leo Murray-Smith a Ãcrit :
> >I was chatting with Rudolf Kastl(che on #winehq) and he was mentioning the
> >things that he was doing for the rpm package. One of the patches he applies
> >to wine prior to packaging it is a patch that creates local user config files
>I was chatting with Rudolf Kastl(che on #winehq) and he was mentioning the
>things that he was doing for the rpm package. One of the patches he applies
>to wine prior to packaging it is a patch that creates local user config files
>if they don't exist.
His patches modify wine/libs/wine/config.
>I was wondering if it would make more sense during the compile process to take
>the default configuration files, config, system.reg, user.reg and userdef.reg
>and convert these to binary form and compile them into the wine binary
>itself. We could detect the lack of these files at startup and
On Wed, 2003-12-17 at 03:15, Dmitry Timoshkov wrote:
> That sounds like a bug either in Window Manager you are using or in
> x11drv code not properly initializing XSetWindowAttributes.event_mask
> (FocusChangeMask). You need further investigate what happens.
Isn't this the same bug that kills us i
Hi,
could you please resubmit your diff using the unified output format? See
http://www.winehq.org/site/sending_patches for details.
bye
michael
On Wed, Dec 17, 2003 at 12:00:56PM +0900, Vik wrote:
> May last patch had some wrong font names for Japanese resource files.
> The correct name
>> >that got truncated. So I would change it to:
>> >
>> >return (int)((*bufferPointer+1)/sizeof(WCHAR));
>> >
>> >Can anybody comment on this? Is this the right fix?
>>
>> Actually MSDN says about SysStringLen:
>>
>> Return Value: The number of characters in bstr
>> Comments: For a BSTR all
23 matches
Mail list logo
