On Thu, Jan 06, 2005 at 10:10:50AM +0100, Peter Berg Larsen wrote:
> No, but it is convinient to have. I need the fullpaths to the .so
> libraries at certain point. Basicly I saw two ways of doing what:
>
> 1) Call [get|guess|try]_lib_path at the that point.
>
> 2) Save all previous result from g
Jonathan Ernst wrote:
This patch removes unused functions from include/util.php
Changelog:
- remove unused functions in include/util.php
Files changed:
- include/util.php
I believe you got carried away...
two of those functions are used by make_bugzilla_version_list():
openbugzilladb() and closebug
Aneurin Price wrote:
I've gone over this patch again, fixed any bugs I could find, and tried
to address the points made regarding readability. Hopefully the coding
style should now be much improved, so could anyone who knows about such
things give it a look over?
Well, it looks nicer, but it p
On Thu, 2005-01-06 at 15:47 -0600, Robert Shearman wrote:
> Actually, we shouldn't be generating assembly code on the fly. If you
> have more than say 16 proxies in a process then it is actually cheaper
> in terms of memory usage and cache locality to have a set of compiled
> entry points that c
Mike Hearn wrote:
On Thu, 2005-01-06 at 02:28 +0100, [EMAIL PROTECTED] wrote:
c) Required to implement DCOM universal interface proxies
required as in 'cannot be implemented any other way'?
I'm not sure. These proxies are run-time generated objects. Essentially
a DCOM universal/type
Hi Aneurin, some style comments on your patch:
+<<< file.c
+===
This shouldn't be in your patch.
+typedef struct
+{
+int flags;
+unsigned int width;
+__int64 precision;
+const MSVCRT_wchar_t *input;
+MSVCRT_wchar_t *output;
+int HeapAlloced;
+union
+{
+
Ivan Leo Puoti <[EMAIL PROTECTED]> writes:
> 23:41 < peter_pan> in the third case, I will have to find a way to
> keep the service process alive (in a stopped state) after
> DriverEntry returns, and use wineserver and ptrace to call the
> callbacks from the user processes. this will imply inter pr
Vincent Béron wrote:
There must exist some tools on the Win32 side of the Earth to deal with
those things...
I searched once for something like this and afair I found only
commercial applications for this. Seems the OSS guys prefer the PO system.
bye
michael
--
Michael Stefaniuc
Am Donnerstag, 6. Januar 2005 18:49 schrieb Jacek Caban:
> Stefan Leichter wrote:
> >Hello,
> >
> >here is a another backtrace of widl with libefence. The crash is from
> >wine-20041227-1114. The patch applied to wine before this snapshot raises
> > the problem. The patch was:
> >
> >Modified files
I've gone over this patch again, fixed any bugs I could find, and tried
to address the points made regarding readability. Hopefully the coding
style should now be much improved, so could anyone who knows about such
things give it a look over? If there's not too much of a problem there
I'll fix
>
OK, it boils down to a regression between wine-20040914 and
wine-20040919: wine won't run, and fails with:
wine: could not exec hUlUhUlUp/bin/wine-pthread
I suppose this problem is not new, since bleeding-edge hoary still
sticks to 20040919.
For the record, here is how to build wine from an amd6
OK, it boils down to a regression between wine-20040914 and
wine-20040919: binaries won't run (wine: could not exec
hUlUhUlUp/bin/wine-pthread).
I suppose this problem is not new, since bleeding-edge hoary still
sticks to this release.
For the record, here is how to build wine from an amd64:
Use t
You can CC me on the mail as well to keep the load on Jeremy down.
Chris
>
> From: Mike McCormack <[EMAIL PROTECTED]>
> Date: 2005/01/06 Thu AM 12:19:45 EST
> To: [EMAIL PROTECTED]
> CC: wine-devel@winehq.com, [EMAIL PROTECTED]
> Subject: Re: [AppDB] Fix to allow creating of new accounts (urge
OK, it boils down to a regression between wine-20040914 and
wine-20040919: binaries won't run (wine: could not exec
hUlUhUlUp/bin/wine-pthread).
I suppose this problem is not new, since bleeding-edge hoary still
sticks to this release.
For the record, here is how to build wine from an amd64:
Use t
> http://source.winehq.org/source/dlls/ntdll/
>
> It's fairly harmless, there is some assembly in there but I don't
> remember seeing any code which assumed an executable stack.
i've looked at it and as i suggested yesterday, it's a false positive.
what happens here is that relay32.s doesn't emit
I thought I'd post an update on where Rob and I are up to, and where
we're going. This is the plan that I have in my head, Rob may want to do
things in a slightly different order etc so don't be surprised if we
change some stuff around as a result of this email.
We're currently reworking, extendin
Stefan Leichter wrote:
Hello,
here is a another backtrace of widl with libefence. The crash is from
wine-20041227-1114. The patch applied to wine before this snapshot raises the
problem. The patch was:
Modified files:
tools/widl : widl.c
Log message:
Vincent Béron <[EMAIL PRO
I'm forwarding this correspondence to wine-devel, in case it interests
other developer / users
Original Message
Subject:
Re: video4linux - wine
Date:
Wed, 5 Jan 2005 22:52:33 +0100
From:
Jasper van Veghel
Vincent Béron <[EMAIL PROTECTED]> writes:
> So if we put them in a simple ok test, we'll get failures for some
> chars, and if we put them in a todo block, then we'll get failures for
> all the other cases which work fine.
>
> We could get on with a todo_table listing for which chars we fail, but
On Thu, 06 Jan 2005 14:19:45 +0900, Mike McCormack <[EMAIL PROTECTED]> wrote:
> Please send mail about security problems with winehq directly to
> [EMAIL PROTECTED] rather than advertising on public mailing lists
> first :)
Agreed, this shouldn't be on a public list. But cc Chris Morgan, Tony
and
Peter Berg Larsen <[EMAIL PROTECTED]> writes:
> Changelog:
> Currently when compiling a program, winegcc calls winebuild
> to solve .def references. But winegcc drops .so files,
> so any new .def symbols in a .so causes a unresolved symbol at
> link time. This patch adds
On Thu, 2005-01-06 at 02:28 +0100, [EMAIL PROTECTED] wrote:
> for historical reasons, there're 2 marks. the older one (controlled by
> chpax) abuses an otherwise (or yet) unused field in the ELF header, i
> personally don't encourage the use of it. the other one (controlled by
> paxctl) is based on
Am Mittwoch, 5. Januar 2005 20:09 schrieb Jacek Caban:
> I know only that it makes widl work for Dan Kegel and Stefan Leichter,
> as they
> reported, but, as often with memory overflow, it can be just a consident.
> Now I see that the bug is not here. The best way to find the bug would be
> to debu
On Wed, 5 Jan 2005, Dimitrie O. Paun wrote:
> On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote:
> > +void strarray_set(strarray* arr, int index, const char* str)
> > +{
> > +if (index >= arr->maximum)
> > +{
> > + arr->maximum = index+10;
> > + arr->base = xrealloc(arr
24 matches
Mail list logo
