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
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
Hi,
Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be
implemented?
AsI 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: StartCom
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 can
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 has on
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 that
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++)
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
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:
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
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
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
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 below
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),
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
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 Signing
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
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]
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
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?
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
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 to
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
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 for
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.
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 !
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
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 documented
28 matches
Mail list logo
