On Thu, Jul 17, 2008 at 7:37 PM, Zac Brown <[EMAIL PROTECTED]> wrote:
> Setup winhttp.h and wininet.h with type guards to allow for use of wininet.h
> in winhttp implementation.
>
> --snip--
>
> Note: I am unsure of whether its better to do this, or finish up winhttp.h
> and then create a private h
On Thu, Jul 17, 2008 at 05:38:29PM -0700, Zac Brown wrote:
>
> +if (dwFlags & WINHTTP_FLAG_ESCAPE_PERCENT ||
> +dwFlags & WINHTTP_FLAG_NULL_CODEPAGE ||
> +dwFlags & WINHTTP_FLAG_ESCAPE_DISABLE ||
> +dwFlags & WINHTTP_FLAG_ESCAPE_DISABLE_QUERY)
if (dwFlags & (WINHTTP
Ok, I'm pretty sure I've got a working wrapper. Still need to implement a
few functions and the direct3d calls but nearly everything is there. If
anyone would like to test out different CUDA apps with this and report any
feedback it would be much appreciate. I don't have a CUDA enabled card so I
ca
Howdy,
> In the future, please attach your test patch to a message in
> wine-devel asking someone to run the test in windows.
I just ran your tests. The new tests ran without problems on my Win2K
and WinXP systems.
However I do have a few other comments. Your formatting is not
consistent with
On Thursday 17 July 2008 22:33:34 Stefan Dösinger wrote:
> How many different conversions do the two games need?
The games I've mentioned before use simple things like X8R8G8B8 to R5G6B5 or
X8R8G8B8 to R8G8B8. By using Google I didn't found much applications with
this particular FIXME (simcity3k
On Thu, Jul 17, 2008 at 2:19 PM, Daniel Santos <[EMAIL PROTECTED]> wrote:
> Since this is my 1st real patch for wine, it's taken me a few iterations to
> get this down. Attached is the updated patch to WSASendTo that includes a
> conformance test. I have NOT run this on windows yet because I don'
Broken patch set :( Please disregard this sequence (1-3) of patches.
I'll send a revised version out later today.
Peace,
-Roy
On Thu, Jul 17, 2008 at 1:37 PM, Roy Shea <[EMAIL PROTECTED]> wrote:
> ---
> dlls/mstask/Makefile.in |2 +
> dlls/mstask/mstask_main.c|5 +-
> dlls/msta
Hongbo Ni wrote:
> --=_35969977==.ALT
> Content-Type: text/html; charset="us-ascii"
>
>
>
>
>
> This patch fixes Bug#14350
> CreateWindowA("Edit"...) should create an Ansi window even
> after the builtin
> Edit class has been subclassed by
> SetClassLongPtrW(hEdit,GCLP_WNDP
Mathias Kosch wrote:
> ...
> The patch and test case were created against wine-1.1.1 and are both
> attached to this mail.
>
> I hope this time I provided enough information
You forgot to mention which versions of Windows you
ran the test case on (and whether it passed there).
- Dan
Michael Karcher wrote:
> Am Donnerstag, den 17.07.2008, 20:24 +0300 schrieb Alexander Dorofeyev:
>> +do
>> +{
>> +hr = IUnknown_Release(pUnkInner);
>> +} while (hr);
> Release returns a ULONG, not a HRESULT. Do we ignore the difference in
> Wine?
I usually do not, but that's ho
How many different conversions do the two games need? One of my concerns is
that this generic code is way slower than a separate conversion function for
each pair of color formats. On the other hand, one function for each pair gives
a whole lot more of code, and if we run into the conversion fun
Hi Owen, this one's another line-limit buster. I won't quote the
lines in this one, as most of it is too long.
--Juan
Hi Owen, this one's another long-liner:
+if (GetWindowTextW(GetDlgItem(hWnd,
IDC_INFO_LABEL), oldtitle, MAX_STRING_LEN) != 0)
+DialogBoxParamW(hInst, MAKEINTRESOURCEW(IDD_INFO), hWnd,
(DLGPROC) SupportInfoDlgProc,
+selitem = SendDlgItemMessageW(hWnd, IDL
Am Donnerstag, den 17.07.2008, 20:24 +0300 schrieb Alexander Dorofeyev:
> +do
> +{
> +hr = IUnknown_Release(pUnkInner);
> +} while (hr);
Release returns a ULONG, not a HRESULT. Do we ignore the difference in
Wine?
Regards,
Michael Karcher
Hi Owen,
this patch goes rather over the suggested line length limit of 80.
Offending lines:
+if (RegOpenKeyExW(root, PathUninstallW, 0, KEY_READ, &hkeyUninst)
!= ERROR_SUCCESS)
+for (i = 0; RegEnumKeyExW(hkeyUninst, i, subKeyName,
&sizeOfSubKeyName, NULL, NULL, NULL, NULL) != ERROR_NO_MOR
Hi Owen,
+ IDS_COLUMN_TITLE_1, "Name"
+ IDS_COLUMN_TITLE_2, "Publisher"
+ IDS_COLUMN_TITLE_3, "Version"
These seem like rather poor names for the string IDs. Why not e.g.
IDS_COLUMN_NAME or simply IDS_NAME?
+/* Definition of column headers for AddListViewColumns function */
+#define NUM_CO
Hi Owen,
-#define ICO_FLOPPY 4
-#define ICO_CDROM 5
-
It seems a little unusual that you remove icon IDs you just introduced
in patch 1. (Probably you shouldn't have included them in the first
place?)
--Juan
Mikołaj Zalewski wrote:
>
>> If someone has the time to look at it, I'd love a pointer on where /
>> how to start investigating this..
>>
>>
> You could try to do a WINEDEBUG=+message,+seh log. This will give you
> all the messages, and a search for seh: lines will give you the
> exceptions
> While valgrinding Picasa, I came across the following valgrind error
> in winefile. (My daily valgrind runs only run the conformance
> suite, which is why I've never seen this before.)
> The lines involved seem unchanged since Martin Fuchs'
> winefile code was merged back in 2002.
>
I have sent
While valgrinding Picasa, I came across the following valgrind error
in winefile. (My daily valgrind runs only run the conformance
suite, which is why I've never seen this before.)
The lines involved seem unchanged since Martin Fuchs'
winefile code was merged back in 2002.
Conditional jump or mov
> The larger a chunk is the harder a review is. I think a patch doesn't
> necessarily have to have a "sensibly" functional result. E.g. you could
> start off with a very skeleton control panel, maybe icons which don't do
> anything. Sure, it's not very functional, but it is very easy to review.
> L
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> Here's what I got from the debug log.
>
> Backtrace:
> =>1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
> [/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
> (0x0032e918)
> 2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b
On 17.07.2008 17:22, Owen Rudge wrote:
> Well, I'm not sure how much smaller I can realistically split them, at
> least, if the individual parts are to be functional, although I guess the
> first and second ones (which are the largest) could be split up a little
> more if that is the reason they
> Perhaps you could split them into smaller parts?
Well, I'm not sure how much smaller I can realistically split them, at
least, if the individual parts are to be functional, although I guess the
first and second ones (which are the largest) could be split up a little
more if that is the reason
> > OK, seems there was a small bug in the last patch that could cause
> > crashes, plus I'd forgotten to include wine.inf.in. I'm pretty sure this
> > one should be fine now, at least. Sorry for all the messages. ;-)
>
> Just wondering if anybody has any feedback on these, as I notice they've
> no
> OK, seems there was a small bug in the last patch that could cause
> crashes, plus I'd forgotten to include wine.inf.in. I'm pretty sure this
> one should be fine now, at least. Sorry for all the messages. ;-)
Just wondering if anybody has any feedback on these, as I notice they've not
been acc
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> Not sure, I just figured it was the program that was doing it? I'll try and
> figure it out and reply back to you as soon as I can.
>
Obvious candidates would be Reset or Uninit3D in device.c, but at
first sight those appear to be safe to call multiple t
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> I noticed this function gets called twice when doing an alt+enter to full
> screen.
>
>From where?
Vladimir Pankratov <[EMAIL PROTECTED]> writes:
> @@ -50,10 +51,17 @@
> int nOldWidth; /* Holds the previous client area width */
> int nOldHeight; /* Holds the previous client area height */
>
> +TCHAR szLoadedString[250]; /* Variable where load string
Eric Pouech <[EMAIL PROTECTED]> writes:
> A+
> ---
>
> dlls/gdi32/tests/bitmap.c |1 -
> dlls/winex11.drv/dib.c|5 -
> 2 files changed, 4 insertions(+), 2 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so
bitmap.c
I noticed this function gets called twice when doing an alt+enter to full
screen.
On Thu, Jul 17, 2008 at 4:35 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> > I added a check to make sure This->shader_priv wasn't null. Before
> > Everquest2.exe would cra
Mikołaj Zalewski <[EMAIL PROTECTED]> writes:
> @@ -116,7 +116,7 @@ STATUSBAR_ComputeHeight(STATUS_INFO *infoPtr)
> TEXTMETRICW tm;
>
> COMCTL32_GetFontMetrics(infoPtr->hFont ? infoPtr->hFont :
> infoPtr->hDefaultFont, &tm);
> -height = tm.tmHeight + 4 + infoPtr->verticalBorder
Am 17.07.2008 um 11:21 schrieb Chris Robinson:
> The cross-compiler comes with win32 import/static libs. Since MinGW
> is a
> Windows port of GCC (and the cross-compiler is basically a port
> back), the
> libs it comes with are native Windows. The -L switches, however,
> point the
> compile
>If someone has the time to look at it, I'd love a pointer on where / how
>to start investigating this..
>
>
You could try to do a WINEDEBUG=+message,+seh log. This will give you
all the messages, and a search for seh: lines will give you the
exceptions that are being thrown/handled. Often,
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> I added a check to make sure This->shader_priv wasn't null. Before
> Everquest2.exe would crash when I tried to alt+enter from windowed mode.
> This stops it crashing wine.
>
This->shader_priv shouldn't be NULL. It probably means the backend was
already
Jon Griffiths <[EMAIL PROTECTED]> writes:
> +while (send_len)
> +{
> +wsabuf.len = send_len;
> +if (wsabuf.len > chunk_len)
> +wsabuf.len = chunk_len;
> +if (!ReadFile(packet->u.s.hFile, wsabuf.buf, wsabuf.
Alexander Dorofeyev <[EMAIL PROTECTED]> writes:
> @@ -1148,7 +1201,7 @@ static const IFilterMapper2Vtbl fm2vtbl =
>
> static HRESULT WINAPI FilterMapper_QueryInterface(IFilterMapper * iface,
> REFIID riid, LPVOID *ppv)
> {
> -FilterMapper2Impl *This = impl_from_IFilterMapper(iface);
> +
On Thursday 17 July 2008 01:43:26 am Markus Hitter wrote:
> Am 17.07.2008 um 00:56 schrieb Chris Robinson:
> > Try linking with MinGW's libs, not Wine's.
>
> My understanding is, MinGW dosn't come with libs, but uses the native
> (Windows) ones.
The cross-compiler comes with win32 import/static li
Am 17.07.2008 um 01:04 schrieb Stefan Dösinger:
>> -lopengl32 -lglu32 -o OpenGLBase.exe OpenGLBase.cpp
>> /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x10e): undefined reference to
>> [EMAIL PROTECTED]'
> I think this is in gdi32.dll
Thanks for the suggestion. Tried to add them, but it doesn't ma
G'day all,
I'm playing with a windows program used to develop code for a uC. The
application is free to download and installs cleanly with no dependence
on external hardware. It's pretty much working except for two details.
A) The file tree on the left of the application throws an application
On Thursday 17 of July 2008 04:07:29 you wrote:
> "Piotr Caban" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED] +/*** LibXML callbacks
> ***/
> +static void libxmlStartDocument(void *ctx)
> +{
> + saxlocator *This = ctx;
> + HRESULT hr;
> +
> + if(This->saxreader->contentHandler)
> +
"James Hawkins" <[EMAIL PROTECTED]> writes:
> Anything wrong with this patch? While the commit in question is right
> in some ways, it's not completely correct and breaks the Office
> installers.
You should add fixes on top of it instead of reverting then redoing it,
that makes a mess of the his
"Juan Lang" <[EMAIL PROTECTED]> writes:
> Depends on the iphlpapi patches I just sent.
You should do the code move in a single patch so that it's seen as a
real move, instead of a copy and then a delete two commits later.
--
Alexandre Julliard
[EMAIL PROTECTED]
Am 17.07.2008 um 00:56 schrieb Chris Robinson:
> On Wednesday 16 July 2008 03:38:37 pm Markus Hitter wrote:
>> maybe I'm just missing the obvious, but I can't get my small one-file
>> app to link. As I've just built Wine from scratch on this box,
>> everything should be installed, including libGL
44 matches
Mail list logo
