On Jan 28, 2008, at 8:06 AM, Misha Koshelev wrote:
> I have started playing with wine on MacOS in VMWare.
> wineprefixcreate page faults on my
> MacOS "system" and I tracked it to Port_SendToMessageThread staying
> NULL because of:
> err:wave:CoreAudio_WaveInit AudioHardwareGetProperty:
> CoreAudio_DefaultDevice.outputDeviceID == kAudioDeviceUnknown
> Clearly wineprefixcreate shouldn't be page faulting under any
> condition.
It seems to me that the driver ought to just fail to load in this
case. If you back out your patch and apply the attached patch, does
that fix the page fault?
-Ken
On So, 2008-01-27 at 21:18 +0100, Alexander Nicolaysen Sørnes wrote:
> SHELLEXECUTEINFOW sei;
> + OSVERSIONINFOW vi;
> WCHAR *args = NULL;
> - int i;
> + int i = 1;
>
The idention show a mismatch between SPACE and TAB
--
By by ... Detlef
On Sunday 27 January 2008 06:42:45 EA Durbin wrote:
[ I decided to CC wine-devel since you're the second person to ask ]
> You had completed some work on winhttp and provided a snapshot in bug 9200.
> Has this been sent to wine-patches yet? I was going to tinker with it a bit
> to see if I could get an app working and wondered if you had anything more
> up to date or if this had been merged into git yet? If you've already got
> a solution I don't want to reinvent the wheel.
Here's a rediffed version of my unfinished winhttp patch. I wrote it primarily
to explore the option of implementing winhttp on top of wininet.
Basically we are faced with a choice between this option, which requires
a Wine-only extension to wininet to implement winhttp style callbacks, and
duplicating wininet code.
I think layering can be done in a relatively clean way by making wininet
handle the superset of wininet and winhttp callbacks and adding callback
filtering as required by winhttp. Old wininet behavior can then be obtained
by an implicit filter on the wininet subset of callbacks.
If time permits I'll write a comprehensive test suite for winhttp which
should help us make an informed decision.
-Hans
"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote:
> + NOTE: This will only work when run from Wine's cmd, but that's ok as start is a builtin
> + shell command on NT */
What's the purpose of the comment above?
> + if(argc > 1 && (vi.dwMajorVersion >= 5 || (vi.dwMajorVersion == 4 && vi.dwPlatformId == 2)))
Unless there is an app which would break because of the title set there is no
need to check the version.
> + {
> + int cmdcount;
> + WCHAR* cmdline = GetCommandLineW();
> + WCHAR** cmdargs = CommandLineToArgvW(cmdline, &cmdcount);
> + WCHAR* pos = cmdline;
wmain() already has arc/argv pair of parameters, why do you need to parse
command line again?
> +
> + pos += lstrlenW(cmdargs[0]);
> +
> + while(*pos == ' ')
> + pos++;
> +
> + if(*pos == '"')
> + {
> + /* FIXME: Set the process title */
> + i++;
> + }
> + LocalFree(cmdargs);
> + }
I assume that you've added LocalFree as MSDN suggests, but CommandLineToArgvW
in Wine uses GlobalAlloc, perhaps you could fix that?
--
Dmitry.
I've been as annoyed as anybody at the huge churn
on wine-bugs lately, it makes it hard to actually read,
and the mailing list archive can't really cope.
But there seems to be no way around it, so I
decided to get a bunch more out of the way
in one fell (and I do mean fell) swoop.
In particular, I closed over a thousand old
RESOLVED FIXED,
RESOLVED ABANDONED,
RESOLVED WORKSFORME, and
RESOLVED INVALID bugs tonight.
You can see the effect here:
http://bugs.winehq.org/reports.cgi?product=Wine&datasets=RESOLVED%3A&datase…
The only real benefit of this is fixed bugs will show
up with strikethrough now when referenced in bugzilla,
which is actually kind of nice.
I'd like to get all the wine-bugs churn out of the way
during January, if possible.
For reference, the rule of thumb for closing RESOLVED bugs is:
FIXED and WORKSFORME: can be closed after two weeks (i.e. after release)
ABANDONED: can be closed after three months
INVALID: can be closed immediately, but if it's less than
a couple months old, check to make sure somebody
wasn't just being cranky
- Dan
Hi all,
I need dump the data using the debug log.
trace:winsock:WSASendTo socket 00f8, wsabuf 0x34e1e0, nbufs 1, flags 0, to
(nil), tolen 0, ovl (nil), func (nil)
if have this one, can i dump the data in 0x34e1e0 with another option in debug,
or i need change the source?
thanks a lot,
--
_______________________________________________________________________________
Juan Carlos Montes Senra
INTECO-CERT
Instituto Nacional de TecnologÃas de la Comunicación
email: juancarlos.montes(a)inteco.es | jcmontes(a)cert.inteco.es
Tlf. 0034 987 877 189 - ext. 532
_______________________________________________________________________________
"Reece Dunn" <msclrhd(a)googlemail.com> wrote:
> This patch ignores any files generated by the Visual C++ compiler to
> make it easier to generate patches when using the VCExpress family of
> compilers on Windows.
There is no point in that, patches should be generated after testing
in Wine under a supported platform.
--
Dmitry.