On Thursday 22 April 2004 19:37, Alexandre Julliard wrote:
Alexandre, can we add this flag to our makefiles? If so,
I can produce a patch...
No, I think it's better to avoid this. Our test environment is useful
for testing not only Wine but also Mingw, we have already found a
number of
Hi,
kernel/tests/generated.c currently shows one failure
when the executable is compiled with MinGW. Investigation
shows that MinGW and GCC differ when it comes to alignment
of doubles (i.e. a 64 bit wide type).
I have constructed the test below that shows the difference
between MinGW and GCC.
On Monday 03 May 2004 14:05, Dmitry Timoshkov wrote:
I think that a correct way deciding whether a struct is correctly
packed is to make sure that our generated tests for packing issues
work under MSVC, then just compare the results. Otherwise we risk
to miss something.
Sure, but until my
On Sunday 23 May 2004 10:07, Rein Klazes wrote:
I do not get out of memory boxes. Here the program tries to open its own
program file:
Stupid program, it first copies itself to the %TEMP% directory. I
happened to run it from there already.
Then it extracts another executable into %TEMP%,
On Saturday 10 July 2004 20:15, Mike McCormack wrote:
Consider adding msi = native, builtin to your Wine configuration
files, and not installing the MSI redistributables straight away when
you encounter an installer that uses msi.dll :) Let us know what bugs
that turns up.
When I do
On Friday 30 July 2004 05:48, Robert Reif wrote:
Unfortunately someone must have copied my mistake and placed them in the
mingw dxguid.lib. So wine's code is now correct for wine and Windows but
Well, not by mistake. I'm maintaining a version of MinGW
(at http://mirzam.it.vu.nl/mingw) with a
On Saturday 24 July 2004 01:18, Francois Gouget wrote:
Exactly. I got my libdxguid.a from the following URLs a couple of days
ago:
http://mirzam.it.vu.nl/mingw/
I thought that was the special 'Wine edition' MinGW library but
apparently not. Where can I find the special 'Wine edition'? I
On Monday 09 August 2004 11:17, Dmitry Timoshkov wrote:
- if (GetLastError()==NTE_BAD_KEYSET)
+ LONG gle = GetLastError();
+ if (gle==NTE_BAD_KEYSET)
This is ugly. This kind of fixes clutters Wine code and should be
deprecated.
What do you propose then? I could do something like this:
On Monday 09 August 2004 12:17, Hans Leidekker wrote:
variable. We somehow have to live with the fact that NTE_BAD_KEYSET
is defined as ((HRESULT)0x80090016L), which is signed, and GetLastError()
returning DWORD, i.e unsigned.
On a related note, I am looking at the last testsuite with signed
On Thursday 12 August 2004 17:31, Francois Gouget wrote:
./tools/winapi/winapi_extract --pseudo-stub-statistics --no-verbose --no-progress
loader/preloader.c: 226: syntax error: 'ElfW(auxv_t) *av'
I have looked into this in the past and IIRC winapi does
it's own C parsing, but has no
On Friday 13 August 2004 13:55, Francois Gouget wrote:
* compiling the test with the Windows headers may result in different
sizes/alignments if the Wine headers got the packign wrong. If that's
the case, the compiler will put in different values for sizeof(struct X)
which will result in
On Thursday 2 September 2004 13:26, Francois Gouget wrote:
Running make crosstest in dlls/mlang/tests I get:
i586-mingw32msvc-gcc mlang.cross.o testlist.cross.o -o
mlang_crosstest.exe -lole32 -lgdi32 -lkernel32 -lntdll -luuid
mlang.cross.o(.text+0x469e): In function `func_mlang':
On Saturday 4 September 2004 14:25, Mike Hearn wrote:
Make apps that search for the DLL files directly happy by creating empty
files for each shipped library
There are applications (eDonkey is one of them IIRC) that call
LoadLibray() themselves on a number of DLLs. Could be that they do
their
On Saturday 4 September 2004 15:28, Mike Hearn wrote:
LoadLibrary should check the Wine DLL path first, as far as I know at
least for DLLs that default to builtin. So if the program does
LoadLibrary(c:\windows\system\user32.dll) for instance, it should still
load the builtin DLL just fine. At
On Saturday 4 September 2004 16:29, Mike Hearn wrote:
Well, yes, I know. But solving that one 100% reliably means making a
cross compiler a buildreq of Wine, and that would be a big pain not to
That would be developer pain traded for user pain. We like that don't we?
mention the difficulty
On Sunday 5 September 2004 07:53, Dan Kegel wrote:
On the console, I saw only the four warnings/errors:
fixme:msi:MsiInstallProductW L/iH:\\IS3123.tmp\\netfx.msi L
fixme:msi:MSI_OpenDatabaseW open failed r = 80004005!
Installation of /iH:\IS3123.tmp\netfx.msi () failed.
On Tuesday 7 September 2004 10:58, Mike Hearn wrote:
Well, we seem to be in a bit of a quandry then. Some apps require the
DLLs to be physically present, and others can't deal with it if they are
but empty. So the only solution seems to be to actually have real PE
DLLs in the virtual
On Saturday 18 September 2004 19:47, Robert Shearman wrote:
Is adding this to the Wine tree likely to break more apps than it fixes?
Well, I don't have real numbers but MSCMS 2.0 is around since Windows 98,
so I'd say most apps that use it expect it to be present. Those are broken
on Wine now,
On Sunday 19 September 2004 06:06, Dmitry Timoshkov wrote:
LittleCMS library. I had to resort to some rather ugly preprocessor
trickery to be able to include lcms.h, since it happens to define basic
Windows types when not compiled on Windows ;-(.
Then perhaps it's better to make lcms.h
On Sunday 19 September 2004 14:43, Robert Shearman wrote:
No. I am asking whether it will end up sitting there remaining 5%
implemented (I think the 25% on the DLLs status page is a little
generous) because no-one will have the time and expertise to implement
the rest. Admittedly, this is
On Sunday 19 September 2004 17:31, Dimitrie O. Paun wrote:
It's probably best to also try to submit a patch to the Little CMS folks
so we can have a better solution in the future.
Sure, will do.
-Hans
On Thursday 23 September 2004 06:02, Steven Edwards wrote:
Feel free to drop the gettimeofday part from this patch. There are 16
other source files where we call gettimeofday in Wine and I am sure if
you dont accept it I can come up a good implementation in libwine.
Why not use Windows time
Mike Hearn wrote:
Hehe, OK. Somebody should write down the Zen of Unix so future followers
of its teachings can learn :)
[ Sorry, this is off-topic ]
Eric Raymond tries to do exactly that in his book called 'The Art of
Unix Programming':
http://www.catb.org/~esr/writings/taoup/
Notice there's
On Friday 15 October 2004 05:40, Kevin Koltzau wrote:
I think I've found the problem, mingw-w32api does not have mscms
With this patch my build runs successfully
Yes, I probably should have mentioned here that there's a new set of
MinGW RPMS on this page:
http://mirzam.it.vu.nl/mingw/
that
On Saturday 25 September 2004 20:29, Hans Leidekker wrote:
Changelog:
Implement color profile handles.
Implement OpenColorProfile{A,W} and CloseColorProfile.
Is there anything wrong with this patch?
-Hans
On Thursday 30 September 2004 23:35, Rolf Kalbermatter wrote:
I don't think this will work properly. The returned pointer from CRYPT_LMHash()
will never be passed out to the caller of the function. There should be
probably a function call before the return of the function along the lines
Ah
On Tuesday 5 October 2004 08:37, Martin Fuchs wrote:
I tried building from the top, from libs/wine/, libs/port/, from some
dlls/... and programs/... directories.
When building from the top, I am getting:
make[1]: Entering directory `/home/cvs/wine/libs'
make[2]: Entering directory
On Tuesday 5 October 2004 10:09, Hans Leidekker wrote:
What compiler/platform are you on? This code is protected like this:
#if defined(__GNUC__) !defined(__MINGW32__) !defined(__APPLE__)
So if you're on Cygwin we may need to add !defined(__CYGWIN__) or
whatever is the appropriate
On Monday 18 October 2004 19:19, Walt Ogburn wrote:
Also, is there a way to make the tests in oleaut32/tests/ run on the
native dlls? If so, I could more clearly show that the Windows version
doesn't null pvData.
Wine's build system has support for cross compiling tests into PE
executables
On Sunday 17 October 2004 16:16, Hans Leidekker wrote:
Changelog:
Add configure check for getpagesize() declaration, needed by MinGW.
Hmm, I just found that the AC_CHECK_DECL macro doesn't work
as expected. You can skip this patch.
-Hans
On Sunday 24 October 2004 01:35, James Hawkins wrote:
The reason why I said to ignore this patch is because there has to be
both an A and a W version of it. I'm pretty sure that this cast:
No, I believe this is an exception. I assume that the spec file
is correct in that there are no A and
On Tuesday 26 October 2004 02:51, Alexandre Julliard wrote:
+INT WINAPI WSAEnumProtocolsA( LPINT lpiProtocols, LPWSAPROTOCOL_INFOA lpBuffer,
LPDWORD lpdwLength )
+{
+ return WINSOCK_EnumProtocols( lpiProtocols, (WSAPROTOCOL_INFOW *)lpBuffer,
lpdwLength, FALSE );
+}
You cannot
On Tuesday 26 October 2004 17:20, Michael Jung wrote:
There is also a DES implementation in dlls/advapi32/crypt_des.c. However, this
one is not exported by advapi32.dll. I could copy the code over to
The DES code is used internally to produce LanManager password hashes. I
doubt if you could
different apps you want to serve. The user uses IE to navigate to that
page. When clicking, the App comes up as a window in his/her machine.
First time visit Installs a 12M Cygwin/X server.
I really like the concept but your approach seems to limit publishing of apps
to Windows boxes.
On Monday 1 November 2004 16:27, Boaz Harrosh wrote:
Actually all it is on windows is a shell access with an invocation of
ssh -X, And the regular IE's safe-for-scripting stuff.
(ssh is installed along side with the cygwin/X server)
I think the use of ssh is a good choice because it let's
On Monday 1 November 2004 17:38, Markus Amsler wrote:
My approach was the following:
Server side:
- defining a mime-type application/x11-control (or something similar)
- a x control file, with all the information to connect to the
Defining your your own mime-type has a disadvantage in
On Saturday 6 November 2004 15:52, Dmitry Timoshkov wrote:
+ else if(!strcasecmp(argv[i]+2, b+!))
Please use lstrcmpiA instead of strcasecmp. A difference between unix
system locale and current ANSI code page in Wine might lead to undesired
side effects.
Here's a patch relative to my
information for hhctrl.ocx
+ *
+ * Copyright 2004 Hans Leidekker
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License
On Monday 8 November 2004 14:20, Dan Kegel wrote:
The path failures are all due to t: not existing; when I create
it by hand, those 397 errors go away.
It sounds very much like the startup code that creates c: and z: needs
to also create a t: drive!
What do your $TMP and $TEMP look like?
On Monday 8 November 2004 17:11, Dan Kegel wrote:
What do your $TMP and $TEMP look like?
In the Unix shell before I start wine, they are
both unset.
I was asking because the path test uses GetTempPath which looks at
$TMP and $TEMP. My $TMP and $TEMP are unset as well and I don't have
a t:
On Thursday 18 November 2004 01:31, Sven Paschukat wrote:
I found out that integrating version information in the builtin
hhctrl.ocx caused this effect. Look into the newest version of
wine/dlls/hhctrl.ocx/Makefile.in and version.rc.
Is this done wilfully or is it a bug?
Well, not having
On Thursday 18 November 2004 22:45, Sven Paschukat wrote:
What about Tom's suggestion setting a more realistic -lower- version in
builtin hhctrl.ocx? Version number 10.0 is good for applications needing
hhelp functionality, but not for them with installers.
Yes, that may work if there is a
On Saturday 20 November 2004 00:53, [EMAIL PROTECTED] wrote:
I am attempting to install the a
href=http://televantage.activelogic.com;TeleVantage Client/a
into wine. I have compiled Wine-20041019 from source.
Upon running the installer, I get way too many errors:
[many MSI errors]
I
On Sunday 21 November 2004 03:23, Tom wrote:
I cant find WinZip 10 ... I thought they may of had a beta out
that is why I ask about it. I guess Hans ment WinZip 9 SR1 in
this post.
http://www.winehq.org/hypermail/wine-devel/2004/11/0412.html
Yes I should have written 9, not 10, sorry. I
On Monday 22 November 2004 09:48, Gerald Pfeifer wrote:
gmake[2]: Entering directory `/.amd_mnt/nashira/files5/test/wine/dlls/mscms'
/sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include
-D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2
On Monday 22 November 2004 12:15, you wrote:
/usr/local/include/lcms.h, coming from a package called lcms-1.09.
Right, that's a very old version from 2001. Since then the number of APIs
has nearly doubled:
$ grep LCMSAPI tmp/lcms.h | wc -l
88
$ grep LCMSAPI /usr/include/lcms.h | wc -l
162
I'm
On Tuesday 23 November 2004 11:32, Scott Ritchie wrote:
4) What I didn't find is a standard list of packages that aren't
strictly required for wine (like libxt-dev and flex), but that wine can
benefit from. A good example would be the alsa development files.
These are all things that should
On Tuesday 23 November 2004 10:21, Francois Gouget wrote:
I'm sure we will be needing many of those newer APIs. Is there any
chance for you to upgrade your lcms.h to 1.13?
A better solution would probably be to check for one of the newer APIs
in configure.ac (or the LCMSICCPROFILE
On Tuesday 23 November 2004 14:07, Francois Gouget wrote:
What I meant is that we should check for one of these new APIs that we
need, and if we don't find it we should just do as if lcms.h was
missing.
Yes of course, I meant that too, and we should do that. But you presented
this as a
On Wednesday 24 November 2004 13:13, Francois Gouget wrote:
I do think it's a better solution. Just like it's better to let Wine
compile even if the ALSA development libraries are not installed or
obsolete, eventhough the resulting winealsa is going to be
non-functional.
Agreed again
On Thursday 25 November 2004 02:08, Vincent Béron wrote:
A packager has to target something (a distro, etc.). If your target has
A packager could target a single distro and version, like you seem
to do. A packager could also target multiple versions of the same
distro (like Ivan does) and a
On Tuesday 28 December 2004 15:30, Stefan Leichter wrote:
you missed to send the implementations of the stubs!
Well, yes and no. Our unicows doesn't have any implementations itself, it
just links to the dlls that do have them by creating dummy references. For
those dlls I sent patches earlier,
On Wednesday 12 January 2005 22:12, Ferenc Wagner wrote:
SF downloads page. Paul Millar, however, kept up with the
load until the new GUIDs broke MinGW again. We already
talked about the issue and Hans Leidekker also confirmed the
MinGW problem, but hasn't got around to provide a patch yet
On Thursday 13 January 2005 15:23, Paul Millar wrote:
In uuid.c, only the one difference:
From Stefan
+DEFINE_GUID(IID_IMAPIPropData,0x2031A,0,0,0xC0,0,0,0,0,0,0,0x46);
From Hans
+DEFINE_OLEGUID(IID_IMAPIPropData,0x2031A,0,0);
Both are correct (the DEFINE_OLEGUID resolves to the
On Friday 14 January 2005 21:31, Stefan Leichter wrote:
i had a build problem with the new rpms. The gcc rpm registers itself as
mingw-gcc-3.4.2-10hl, but the mingw rpm (runtime, w32api) requires
mingw-gcc-core for its build.
Fixed now, thanks.
-Hans
On Saturday 11 April 2009 05:14:25 Nicolas Le Cam wrote:
Your patch makes the test timeout on my machine
(http://test.winehq.org/data/f212579ae9a1b770ebd34cec20f95e1977bb57f0/2000_w2k-sp4-fr/wininet:http.html).
Timeout occurs in HttpSendRequestEx_test on HttpEndRequest call which
hang.
On Saturday 11 April 2009 15:20:06 Nicolas Le Cam wrote:
Is there no way to avoid use of cached connections or to clean the
cache before those two tests ?
Perhaps moving both tests up and down instead of sleeping at end of
them could help.
I looked for a way to disable it but couldn't find
On Monday 20 April 2009 20:14:14 Nicolas Le Cam wrote:
Win2k SP4 seems to be the only platform that follows what msdn says (see
http://msdn.microsoft.com/en-us/library/aa384247(VS.85).aspx).
wininet is bundled with Internet Explorer, so it's more useful to look at
the Explorer version than the
On Thursday 23 April 2009 18:46:38 Austin English wrote:
diff --git a/dlls/winhttp/net.c b/dlls/winhttp/net.c
index 79e6789..3c68ee0 100644
--- a/dlls/winhttp/net.c
+++ b/dlls/winhttp/net.c
@@ -82,7 +82,7 @@ static CRITICAL_SECTION cs_gethostbyname = {
critsect_debug, -1, 0, 0, 0, 0 };
-( `Property` CHAR(255), `Value` CHAR(1) PRIMARY KEY
`Property`) );
+( `Property` CHAR(255), `Value` CHAR(1), `Intvalue` INT PRIMARY
KEY `Property`) );
ok( r == ERROR_SUCCESS , Failed to create table\n );
...
ok( check_record( rec, 2, Value), wrong record
On Wednesday 29 April 2009 10:08:56 am Paul Vriens wrote:
Was going through some logs on Bugzilla and noticed this.
Changelog
Don't print an out parameter
The spec entry for ClusterEnum also needs a fix.
-Hans
Dear Wine developers,
You may recall that I volunteered to help host WineConf in the Netherlands
in 2007 when, after a vote, an offer by Dan Kegel to host at Google's offices
in Zurich won the bid.
Last year WineConf went across the pond to Minnesota, so it seems natural
that this year's
On Thursday 04 June 2009 10:12:02 pm Austin English wrote:
One of your recent msi patches (I suspect this one), causes several
hundred failures/succeeding todo's on my previously passing box. Could
you have a look:
On Tuesday 16 June 2009 11:15:49 am Jacek Caban wrote:
diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c
index 8f9f404..2721427 100644
--- a/dlls/wininet/http.c
+++ b/dlls/wininet/http.c
@@ -3807,8 +3807,7 @@ BOOL WINAPI HTTP_HttpSendRequestW(LPWININETHTTPREQW
lpwhr, LPCWSTR
Hi Dan,
+/* Dummy thread just to initialize an MTA for the benefit of custom action
DLLs */
+static HANDLE dummy_thread_event = NULL;
+static HANDLE dummy_thread_handle = NULL;
+
+DWORD WINAPI dummy_thread_proc(void *arg)
It appears that calling CreateThread in DLL_PROCESS_ATTACH can
On Sunday 21 June 2009 07:39:39 pm Dan Kegel wrote:
I'm more worried about thread shutdown.
It seems wrong to just hope that the thread finishes terminating
before DllMain returns and the system calls FreeLibrary,
but as oldnewthing explains, you can't wait for a thread to
terminate inside
On Wednesday 01 July 2009 12:12:47 pm Paul Vriens wrote:
Would using IsValidCodePage() be helpful here?
Yep, something like:
hr = IMultiLanguage2_IsCodePageInstallable(ml2, i);
if (i == 29001 || /* win2k3 */
i == 50930 || i == 50931 || i == 50933 || i ==
On Wednesday 01 July 2009 01:09:52 pm Alexandre Julliard wrote:
IsValidCodePage might be helpful yes, although marking it broken is
a bit too strong I think, it's just a difference in codepage databases.
-Hans
Yes, broken() seems strong but it's actually meant as
Hi Juan,
-*sa_len = sizeof(struct sockaddr_in);
-memset( sa, 0, sizeof(struct sockaddr_in) );
-memcpy( ((struct sockaddr_in *)sa)-sin_addr, ((struct sockaddr_in
*)res-ai_addr)-sin_addr, sizeof(struct in_addr) );
-((struct sockaddr_in *)sa)-sin_family = res-ai_family;
-
On Saturday 01 August 2009 12:47:33 am Dan Kegel wrote:
But I didn't have any joy when I tried it, hence my question.
Here's a recipe for the standalone installer that works for me
after applying the patch attached to this e-mail:
$ sha1sum dotnetfx3.exe
On Saturday 01 August 2009 02:51:14 pm Dan Kegel wrote:
It's slow towards the end, too slow I think, but eventually it completes
here.
That's good news. That patch looks meatier than the similar
patches by Aric and Louis that were posted to wine-patches earlier.
How close is it to
Fixes http://bugs.winehq.org/show_bug.cgi?id=19636
Or it doesn't:
err:ole:CoInitializeEx Attempt to change threading model of this apartment from
multi-threaded to apartment threaded
err:shell:ShellLink_QueryInterface -- Interface: E_NOINTERFACE
Because IShellLink is apartment-threaded only?
Hi Juan,
These patches collectively fix bug 18364, which was a crash in OpenSSL
in a multithreaded app (utorrent.exe.)
The bug reporter sees long delays between torrents starting up after
applying these patches, which makes we wonder if the ssl lock effectively
serializes secure https
Hi Nate,
Your patch applies with offsets, please rebase to current git.
And get rid of this warning:
db.c: In function ‘test_where_not_in_selected’:
db.c:1576: warning: unused variable ‘count’
+query = /*Select IESTable.Action, IESTable.Condition from CATable,
IESTable where */
+
On Thursday 01 October 2009 08:46:13 pm Paul Vriens wrote:
+RegOpenKeyExA(HKEY_LOCAL_MACHINE, key, 0, KEY_ALL_ACCESS,hkey);
+if (!RegQueryValueExA(hkey, value, NULL, NULL, NULL,size))
+{
+skip(Pending file rename operations, skipping test\n);
+return;
Hi
On Tuesday 13 October 2009 08:46:59 am Dmitry Timoshkov wrote:
+ret = pCryptImportKey(provider, (BYTE*)key_blob,
+ sizeof(BLOBHEADER)+sizeof(DWORD)+key_length,
+ 0, CRYPT_IPSEC_HMAC_KEY, hkey);
+ok(ret, CryptImportKey error %u\n,
On Monday 19 October 2009 04:19:07 Nathan Gallaher wrote:
Resubmit of patch.
Patch separated into test and fix components.
Patch rebased.
tableName variable -- table_name
Commented code removed.
Unused variables removed
Unnecessary debug printf's removed.
Looks good, please submit the
On Tuesday 20 October 2009 10:07:07 am Paul Vriens wrote:
In an effort to get everything green I'm trying to fix some long
standing setupapi test failures.
In one of the tests, test_SetupDecompressOrCopyFile() in misc.c, we call
SetupDecompressOrCopyFileA a few times. One of them fails as
On Wednesday 21 October 2009 17:22:08 Juan Lang wrote:
-size = (lstrlenW(value) + 1 + size) * sizeof(WCHAR);
+size += (lstrlenW(value) + 1) * sizeof(WCHAR);
I don't see how you're avoiding accessing uninitialize memory here.
Could you enlighten me?
size is calculated in
On Friday 30 October 2009 14:10:27 Michael Martin wrote:
Add check for ERROR_USER_MAPPED_FILE in addition to ERROR_SHARING_VIOLATION
when scheduling a rename operation. ERROR_USER_MAPPED_FILE can be set when
trying to overwrite true type fonts in windows.
For more info see
On Saturday 31 October 2009 05:22:31 you wrote:
I haven't came across an installer yet that fails on WINE because of this.
I have jumped ahead a bit here.
Regardless, if a file has been mapped by using CreateFileMapping/MapViewOfFile
and the CopyFile api (having the last parameter as FALSE)
On Saturday 31 October 2009 11:10:35 Michael Martin wrote:
Understand,
I guess ill write some wine test to check different return values for
differences on mapped files.
Can you give me a pointer on where this would best fit in?
kernel32/tests/file.c: test_CopyFileW, or should i make my
On Monday 09 June 2008 17:09:52 Alexandre Julliard wrote:
The bug is in InternetCrackUrlW, it shouldn't require the string to be
null-terminated.
Right, but I guess fixing that is no 1.0 material since there's at least
4 places where it assumes a null-terminated string, including a call to
On Monday 30 June 2008 09:05:42 Ivan Sinitsin wrote:
Fix propblem with command `wine start http://something` when version of
windows NT.
When version NT we have WCHAR and don`t need to transform char to WCHAR.
I believe it's not the windows version that determines whether the data
retrieved
On Tuesday 01 July 2008 21:42:30 Zac Brown wrote:
Does anyone have thoughts on implementing parts of winhttp in terms of
wininet? The primary issue that prevents entirely implementing winhttp in
terms of wininet is that there is no direct Win32 API for fetching an SSL
certificate in winhttp.
On Wednesday 02 July 2008 23:56:51 Rob Shearman wrote:
How about:
3) Copy the networking sublayer from wininet into winhttp and build on top
of that to implement winhttp. Reimplement wininet on top of winhttp.
Drawback to this option is that you're going to destabilize wininet, but
perhaps
On Wednesday 02 July 2008 19:27:43 Yann Droneaud wrote:
This patch does the following:
- Move cookie retrieval code to HTTP_HttpSendRequest()
- Don't allocate memory for url if INTERNET_FLAG_NO_COOKIES is enabled
- Be sure to not overflow lpszCookies:
buffer size was nCookieSize + 1 + 8,
On Thursday 03 July 2008 12:18:14 Yann Droneaud wrote:
Thanks Yann, good to see you move on to fix more bugs. To be accepted
in git each of those items should be a separate patch though, and the
impact of moving the cookie code is such that it needs a test case.
Please, don't ask me to
On Friday 04 July 2008 10:15:57 Alexander Morozov wrote:
+if ((lpwhr-hdr.dwFlags INTERNET_FLAG_NO_CACHE_WRITE)
+CSTR_EQUAL == CompareStringW(LOCALE_SYSTEM_DEFAULT, 0,
+lpwhr-lpszVerb, strlenW(lpwhr-lpszVerb), szPOST,
strlenW(szPOST)))
No need to use CompareStringW
On Friday 18 July 2008 05:45:15 James Hawkins wrote:
I thought the idea was to implement winhttp and then implement wininet
on top of winhttp. Why are you importing wininet?
wininet on top of winhttp is the most promising option but I don't think
a consensus has been reached yet.
A technical
On Friday 18 July 2008 16:11:37 Dan Kegel wrote:
Building winhttp on top of wininet lets us develop on trunk and
is probably the fastest path to making a bunch of applications
happy, isn't it? That's the way I'm leaning, anyway.
True, but that's been tried already:
On Saturday 19 July 2008 02:19:11 Dan Hipschman wrote:
It punts on some integer-wrapping issues. If someone runs their wineserver
for 49 days they may run into that issue. I just thought it would distract
Have you thought about using GetTickCount64 instead of GetTickCount?
-Hans
On Friday 15 August 2008 01:54:19 Huw Davies wrote:
Vincent Povirk wrote:
This is a fix to a problem I introduced in
fd5b97bc4d12adc69085b739061c56e9107f8d1f. The expression that checked
the HTTP version was true for HTTP/1.0 servers, and I treated it as if
it were true for HTTP/1.1
On Friday 15 August 2008 14:41:36 Hans Leidekker wrote:
Sorry for the From address confusion. The CodeWeavers mail server
accused me of relaying but I found out now that it's because I forgot
to enable authenticated SMTP.
-Hans
On Friday 15 August 2008 15:23:40 H. Verbeet wrote:
Not necessarily wrong, but the common way to implement tables like
this is to grow the table by some percentage of the original size, and
keep a list of free handles.
Good point. I'll fix that when we have the basics of this dll covered.
On Wednesday 20 August 2008 20:34:43 Gerald Pfeifer wrote:
This minor change on top of Hans' contributions in the recent days
unbreaks the build on FreeBSD (and likely other BSDs and possibly
Darwin/MacOS).
Thanks. I didn't want to copy all of the ifdef blocks from wininet
because I can't
On Wednesday 03 September 2008 16:37:48 Jacek Caban wrote:
+static BOOL session_set_option( object_header_t *hdr, DWORD option, LPVOID
buffer, DWORD buflen )
+{
+if (hdr-type != WINHTTP_HANDLE_TYPE_SESSION)
+{
+release_object( hdr );
+set_last_error(
On Wednesday 03 September 2008 20:33:25 Nerv wrote:
-It seems Windows XP only increments lpdwIndex if the Function returns
true, so it is fixed if you just look on bSuccess
This patch is likely correct but please do add a test case to prove your
finding.
-Hans
On Friday 03 October 2008 13:23:14 Alistair Leslie-Hughes wrote:
Changelog:
msxml3: Add IXMLHTTPRequest support
Would it be possible to use winhttp instead of nanohttp? The less
we depend on libxml the better I'd say.
-Hans
On Monday 20 October 2008 21:48:37 Juan Lang wrote:
+/* FIXME: verify certificate and determine store name dynamically */
+if (!(store = CertOpenStore(CERT_STORE_PROV_SYSTEM_W, 0, 0,
CERT_SYSTEM_STORE_CURRENT_USER, Root)))
+{
+WARN(unable to open certificate store\n);
+
1 - 100 of 545 matches
Mail list logo
