Dimitrie O. Paun wrote:
A small test in dlls/kernel/tests/*.c for this would be perfect.
In general, it's better to submit such a test, rather than write
a throw-away one on your box only.
You were, like always, right. I did a test and found that Wine is OK
just like in windows.
Probably in th
Hello,
trying to build wine-20040309 in separate build directory.
../wine-20040309/configure completed correctly, but running
make depend gives me:
cd ./tools && make `basename tools/makedep`
make[1]: Entering directory `/usr/src/wine-build/tools'
gcc -c -I../../wine-20040309/tools -I. -I../../wi
Paul Millar wrote:
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
Anyone should be able to reproduce the output by extracting this date
(from the .zip filename, or from winetest.exe), "cvs up -D"-ing and
cross-compiling themselves.
There are several problems with a variable build
Dimitrie O. Paun wrote:
Now, when do we build? I don't think we should trigger the build based
upon CVS commits, we need it a bit more controlled for a variety of
reasons. Here is what I propose:
-- decide on a time at night when the tree is very unlikely to change
(say 4am).
-- every day,
On Mon, 22 Mar 2004, Paul Millar wrote:
> > Yes, I meant EST. Or, as you can see from your graph, 10am GMT is perfect.
>
> OK. Its also the most likely time by which Alexandre has committed all
> the patches for that night (although it doesn't guarantee it). If we had
> to have a fixed build ti
I thought I should mention:
http://cvs.sourceforge.net/viewcvs.py/ofc/ofc/test/
The OFC project actually has a few classes now. Might be of use
to somebody porting stuff to Linux.
Jakob
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> On Mon, 22 Mar 2004, Paul Millar wrote:
> > Does this *really* matter [if] we miss some patches?
>
> Yes, it does matter, and it's rather important. The test cycle is
> non-trivial, as I've already noted. It will take many hours to
> distrib
This patch goes somewhat against Dimi's. Instead of
invoking cvs, it extracts the working revision info from the
CVS/Entries files resulting in speedy operation. Thus I
incorporated all the stuff into maketest, executing
unconditionally. Hope it is still portable.
ChangeLog:
- Extract revision
Hello,
Its time for another round of PSDK porting fixes. I am going to start
on comctl32. Most of if builds fine except for some internal or
non-documented defines that we need to figure out how to handle. The
only big issue we have is listview...
Compiling...
listview.c
C:\source\wine\dlls\comctl
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> +void test_CreatePipe(void)
> +{
> +/* Adapted from the MSDN SDK example
> + * "Creating a Child Process with Redirected Input and Output"
> + */
You can't do that, MSDN examples are copyright Microsoft. You have to
write your own code from s
On Monday 22 March 2004 12:58, Ferenc Wagner wrote:
> > So, should I just do a "make -k" from the base directory
> > and leave broken tests to fail? (I haven't tried with the
> > current code, so this may be redundant now.)
Which tests are broken? I'm able to build all tests with
MinGW. MinGW do
Mike Hearn <[EMAIL PROTECTED]> writes:
> The parameters for these functions have not been verified as in native ddraw.dll
> they are some kind of circular forward, it's rather confusing.
The proper way to determine the number of parameters is to check what
the caller does. And if nobody calls th
hatky <> writes:
> They were in less the 10% of the file and I remeber some talks that said just
> use spaces
> Should I retract that part?
Yes please. If you really want to change whitespace please do it as a
separate patch, don't mix it in with functional changes. But I don't
think changin
On Monday 22 March 2004 11:25, Paul Millar wrote:
> I've also removed the urlmon test from programs/winetest/Makefile.in:
> TESTS variable, just to allow winetest.exe to build. Do you know if
> that's been fixed?
I've created a patch to add an urlmon import lib to the w32api
package of MinGW. It
Paul Millar <[EMAIL PROTECTED]> writes:
> On Mon, 22 Mar 2004, Ferenc Wagner wrote:
>
>> Paul Millar <[EMAIL PROTECTED]> writes:
>>
>>> For some reason, running make inside dlls directory
>>> generated more *_test.exe's than a simple "make -k".
>>
>> I guess this may be caused by the lib*.a impor
On Mon, 22 Mar 2004, Paul Millar wrote:
> Does this *really* matter? If we miss some patches, then WRT will just
> rebuild when it finishes the current cycle. The resulting binaries would
> be published once it done.
Yes, it does matter, and it's rather important. The test cycle is non-trivial,
Hi Ferenc,
On Mon, 22 Mar 2004, Ferenc Wagner wrote:
> Paul Millar <[EMAIL PROTECTED]> writes:
> > For some reason, running make inside dlls directory
> > generated more *_test.exe's than a simple "make -k".
>
> I guess this may be caused by the lib*.a import libs in
> dlls: using those of Wine i
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> > Anyone should be able to reproduce the output by extracting this date
> > (from the .zip filename, or from winetest.exe), "cvs up -D"-ing and
> > cross-compiling themselves.
>
> There are several problems with a variable build time, but th
Paul Millar <[EMAIL PROTECTED]> writes:
> Currently the cross-build does something like:
>make -k; cd dlls; make -k; cd wine-mingw/programs/winetest; make
> but with an old-ish copy of wine CVS.
>
> For some reason, running make inside dlls directory
> generated more *_test.exe's than a simple
On Mon, 22 Mar 2004, Ferenc Wagner wrote:
> > Can I set WINE_BUILD to some fixed value? If so, what's a
> > good one to use?
>
> You can set it to anything that unambiguously identifies
> your build. Something like the date of the latest CVS
> commit.
'k. I'll use the date-stamp from the last
On Mon, 22 Mar 2004, Paul Millar wrote:
> 'k. AFAIK, that won't work like that (because of the COFF/PE internal
> checksum field) but it that's easily worked around: just build twice.
> The second time use the "real" WINE_BUILD date. Shouldn't hurt much.
Right. Moreover, the "fixed" build we
Hi Dimi,
On Mon, 22 Mar 2004, Dimitrie O. Paun wrote:
> > Can I set WINE_BUILD to some fixed value? If so, what's a good one to
> > use?
>
> The WINE_BUILD value must be valid, we can't distribute a winetest.exe
> with a fixed value in there. What you can do is fix it at build time
> to a known
On Mon, 22 Mar 2004, Boaz Harrosh wrote:
> module.c
> GetProcAdress will not "Fly" on a NULL module. It will Just return
> with Error set to ERROR_PROC_NOT_FOUND (127).
> Actually, I did a little check, On ms-windows any garbage HMODULE will
> Just Return an error. Is there a ValidPointer/magi
Paul Millar <[EMAIL PROTECTED]> writes:
> On Sun, 21 Mar 2004, Jakob Eriksson wrote:
>
>> Ivan Leo Murray-Smith wrote:
>>
I am kind of holding my breath for a regular build of
winetest.exe - any chance for that soon? :-)
>>>
>>> It depends on how you define regular. If you mean
>>>
On Mon, 22 Mar 2004, Paul Millar wrote:
> From what I can see, the script programs/winetest/maketest builds the
> winetest.rc file. If the variable WINE_BUILD is set, it is used as the
> first element of the string-table, otherwise an auto-generated string is
> used, for example "20040322.1508-au
On Sun, 21 Mar 2004, Jakob Eriksson wrote:
> Ivan Leo Murray-Smith wrote:
> >>I am kind of holding my breath for a regular build of winetest.exe -
> >>any chance for that soon? :-)
> >>
> >It depends on how you define regular. If you mean daily/weekly builds,
> >I have no idea. But I can build
Boaz Harrosh wrote:
- Where is the official place to download the ICU library for support
of BIDI?
http://oss.software.ibm.com/icu/ is the project's home page. They have
packages for some distros, but not as many as i would like.
Also, when I have some time, there is a way to compile ICU so tha
- Where is the official place to download the ICU library for support of
BIDI?
- Should we not have a BIDI section in documentation?
- Is there a place on winehq with links to extra needed downloads?
should ICU be there 2?
Free Life
Boaz
On Sun, 21 Mar 2004 08:01 pm, Eric Pouech wrote:
> Robert Lunnon a écrit :
> > Well you can ignore my last message, from the source it's pretty obvious
> > why it doesn't work. Linuxisms !
> >
> > At the very least it should be possible to declare a scsi device in the
> > config file and have it se
29 matches
Mail list logo
