On Thursday 15 January 2004 15:53, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > 1. The original cpuid and i386 detect are merged into a single assembly
> > call for convenience.
>
> Much less readable IMO.
A little less readable in my opinion, this assembly code is doc
Yes it works. My QA tested it throughly with MSSQL driver and there are
no reported problems.
The best way to go is a free download from Microsoft. mdac_typ.exe .
Just Install it under wine and off you go. Also many MS applications
Install them (like office).
Than in system folder find cliconfig
Robert Lunnon <[EMAIL PROTECTED]> writes:
> 1. The original cpuid and i386 detect are merged into a single assembly call
> for convenience.
Much less readable IMO.
> 2. The data is then interpreted into a structure for use. Understanding CPUID
> means knowing the cpuid_t structure and CPUID_Is
On Thursday 15 January 2004 06:57, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > Changelog
> > Autodetection of XFREE86 as required for Solaris.
>
> This should be done in configure, assuming it is really necessary. Why
> can't we use the standard Xlib?
It would be nice
On Wednesday 14 January 2004 14:50, Dimitrie O. Paun wrote:
> On January 13, 2004 09:46 pm, Robert Lunnon wrote:
> > +#if !defined sun
> >*mtu = ifr.ifr_mtu;
> > +#else
> > + *mtu=ifr.ifr_metric;
> > + #endif
>
> The #endif is not properly indented, any special reason?
Damned editor
On Thursday 15 January 2004 10:45, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > Improves CPUID instruction support in cpu.c by reorganising the existing
> > FREEBSD code. Added more robust cpuid detection with built in 386
> > detection. Code should work for all i386 pl
Why my patch was not applied? If it will be because it conflicts with the
patches of the ROS, can leave that in the next weekend I intend to make this,
thus diminishes the work of them. But necessary to know if my patch it goes
to be accepted, if I do not go to be losing my time.
Thank you.
E
Hy list,
I like to learn how to fix wine problems myself and am trying to track down an
exception
occuring while starting good old 'Dungeon Keeper'.
For now I have two problems:
1. When I invoke the game with 'wine' and with 'winedbg' I get different exception
messages
(traces see below), why
Robert Lunnon <[EMAIL PROTECTED]> writes:
> Improves CPUID instruction support in cpu.c by reorganising the existing
> FREEBSD code. Added more robust cpuid detection with built in 386 detection.
> Code should work for all i386 platforms and has been tested under solaris.
> Created subroutines
On Wed, Jan 14, 2004 at 02:25:33PM -0800, hatky wrote:
> I run a free program call The All-seeing Eye,
> available for free at:
> http://www.udpsoft.com/eye2/index.html
> And run into a few errors like this:
> err:imagelist:ImageList_Remove index out of range! 0
That's probably only cosmetic, see b
Hello,
I have started to work on winecfg a little in attempt to get used to
some workings of WINE. This is the first real open source project I have
actually tried to submit a patch to. I have started to work on a few
functions that were not implemented yet and before I forget to try to
sub
I run a free program call The All-seeing Eye,
available for free at:
http://www.udpsoft.com/eye2/index.html
And run into a few errors like this:
err:imagelist:ImageList_Remove index out of range! 0
ImageList_Remove gets(
HIMAGELIST himl,
int i)
line 2040 of imagelist.c says:
if ((i <
On Wed, 14 Jan 2004 14:51:13 +0200, MediaHost (TM) wrote:
> Well, I guess, that there are people actively developing...It might be
> easier for them to get a fix done...
It wouldn't be too hard to stub it. Wine doesn't really have any of the
multi-user APIs implemented, there seems little point wh
Hans Leidekker <[EMAIL PROTECTED]> writes:
> Looks like a solution to me. What about dxguid? Should we split
> uuid up by creating a seperate directory with Makefile etc. or
> will a symlink to libuuid do?
I think we should create a separate library. I'm also wondering if we
shouldn't move them
Le mer 14/01/2004 à 12:01, Ivan Leo Murray-Smith a écrit :
> With current cvs, I get this strange warning message
>
[snip]
> gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe
> -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g
> -O2 -o win
Hi Dmitry,
I asked Alexandre where it should go, and he said wine/dlls was an
appropriate place. I don't mind either way...
Mike
Dmitry Timoshkov wrote:
Mike, could you put the iccvid sources at the same place
as msrle32 (dlls/msvideo) and resend the patch?
With current cvs, I get this strange warning message
make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest'
cp ../../dlls/advapi32/tests/advapi32_test.exe.so advapi32_test.exe.so && strip
-s advapi32_test.exe.so
cp ../../dlls/gdi/tests/gdi32_test.exe.so gdi32_test.exe
Robert Lunnon <[EMAIL PROTECTED]> writes:
> Changelog
> Autodetection of XFREE86 as required for Solaris.
This should be done in configure, assuming it is really necessary. Why
can't we use the standard Xlib?
--
Alexandre Julliard
[EMAIL PROTECTED]
On January 13, 2004 08:06 pm, Alexandre Julliard wrote:
> The main problem is that winegcc only knows about gcc, and we want
> Wine to build with other compilers too. So no, we can't use it yet.
Good point. Situation is not too bad though. Wine source is not gcc
specific, so we can invoke whatever
Following a suggestion in Wine User's Guide, (§ 1.1.2), I'd like to suggest
an addition.
The "ODBC" section (§ 5.12) gives details (§ 5.12.1) about the use of the
native ODBC driver, routed through a fake "builtin" ODBC driver. I have not
yet had to test it in real conditions. All I can tell is
This patch replaces the prior patch. The ReactOS changelog wasnt very
good and Martin pointed out that I missed the spec file.
Changelog:
"Martin Fuchs" <[EMAIL PROTECTED]>
Implement RestartDialog and RestartDialogEx
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Sig
Well, I guess, that there are people actively developing...It might be
easier for them to get a fix done...
Until I get into the source and understand, what you guys did.win2000
will have finished end of life :-)
Anyone knows where to insert this piece of code?
Can be found here:
http:/
Dimitrie O. Paun a e'crit :
On January 14, 2004 01:05 am, Dmitry Timoshkov wrote:
I don't mind either, but if the new iccvid code will be placed under
dlls/ then dlls/msvideo/msrle32 should be moved there as well.
I'd much rather move msrle32 to dlls/, then create new DLLs
deep inside the dir hi
I just revisited
http://bugs.winehq.org/show_bug.cgi?id=1268
and found that things are improved, but not fully working;
there is corruption to the left of column 1 in the demo app.
I have not yet rechecked
http://bugs.winehq.org/show_bug.cgi?id=1404
to see how well that demo app is doing.
- Dan
If I look at WWN #110 on winehq.org I get this
http://www.winehq.org/?issue=110
If I look at 110 at : http://kt.zork.net/wine/wn20011212_110.html
it is almost toatly different!!
Do I need to start reading both sites each week?
And I guess ill send a patch to fix this as there is alot of good
crap h
On Tuesday 13 January 2004 23:57, Uwe Bonnes wrote:
> +HANDLE DEVICE_Open( LPCWSTR filenameW, DWORD access, DWORD attributes,
> LPSECURITY_ATTRIBUTES sa )
> {
> const struct VxDInfo *info;
> char filename[MAX_PATH];
> @@ -283,7 +283,7 @@
>
> for (info = VxDList; info->name; info+
On Tuesday 13 January 2004 20:33, Alexandre Julliard wrote:
> this doesn't help. A possibility could be to rename the library to
> libuuid but install it in /usr/lib/wine to avoid conflicts. This will
> require winegcc and winemaker to set the correct library path, but
> they already have to do th
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> appended patch opens the devicefile connected to a drive as connected by the
> user in ~/.wine/config [Drive X] "Device" = "/dev/yyy".
> The appropriate action on that file ( read, write, set_file_pointer, ...)
> succeed
> according the the righte the user
On Wed, Jan 14, 2004 at 11:09:15AM +0200, MediaHost (TM) wrote:
> Hi,
>
> Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be
> implemented?
If someone implements it, yes.
> As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this
> function and
Hi,
Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be
implemented?
As I can see, most up 2 date software of
Micro$oft (Explorer etc.) is using this function and can not run on a W2K
environment.
Any suggestions?
Regards
Signer: Eddy NiggCompany: Star
Running the oleaut32 tests shows that vartype and vartest are failing.
The 25 tests that fail are returning DISP_E_TYPEMISMATCH (0x80020005)
Has someone an idea about these ?
vartest.c:2653: Testing different VARTYPES
fixme:ole:VarParseNumFromStr dwInFlags & NUMPRS_HEX_OCT not y
On January 14, 2004 01:05 am, Dmitry Timoshkov wrote:
> I don't mind either, but if the new iccvid code will be placed under
> dlls/ then dlls/msvideo/msrle32 should be moved there as well.
I'd much rather move msrle32 to dlls/, then create new DLLs
deep inside the dir hierarchy. Ideally we should
32 matches
Mail list logo
