Francois Gouget wrote:
>
> This modifies OSS_Wave{In,Out}Init to report the exact capabilities of
> the OSS driver. The new code does not try to use SNDCTL_DSP_SETFMTS
> since some (old) cards may support 16bit or stereo audio at some sample
> rates but not other (higher) rates. It now also reports the 48kHz and
> 96kHz formats if they are supported.
given the susceptibility of some OSS implementations, I'd suggest
reimplementing the test loop as:
for fmt
for channels
for …
[View More]rates
if open succeeds
1/ flag format as supported
2/ close device
endif
endfor
endfor
endfor
this would also put us out of danger if the device doesn't accept
changing its mode on the fly
A+
--
Eric Pouech
[View Less]
On Wednesday 08 January 2003 12:31 pm, Ove Kaaven wrote:
> Feel free to recompile the .idl files after applying this patch...
> it's not necessary, but sooner or later someone is going to try what
> I'm currently trying... to compile MIDL-generated proxy/stub code
> with Wine headers.
Indeed, I am doing this now with my RPC test. I'm not sure we are
targeting the same stuff, however. You can see my work-in-progress in
the K patchseries, which only has one (rejected) "official" …
[View More]patch: K01.
Actually, what I'm really trying to do is mix and match. I want the .h
header to be generated by widl, and the _s.c and _c.c stubs to be
generated by MIDL.
wire_marshall should be a barrel of laughs ;) Maybe after I get this
batch working I'll whip up some tests for 'ya that use it.
I encounter the following gaps:
o widl doesn't generate forward declarations for MIDL_user_allocate
and MIDL_user_free, should be trivial to fix.
o widl doesn't parse the implicit_handle stuff in the .acf,
which cause MIDL to put an extern declaration in for the handle.
o RpcTry/Except/etc. Ugh, what a $&^@$*% train wreck. More-or-less
unfixable, and not widl's fault anyhow. ATM I may hack around this
using some evil, incorrect, and, frankly, downright offensive macros.
Long term, of course, I'm interested in seeing exception handling
souce-compatibility in wine... perhaps, winegcc, or some cousin, could
parse VC++ __try & family and generate wine-compatible __TRY & family
to match? Given the freedom to parse/generate, regardless of the
implementation specifics, it becomes a surmountable problem IMO.
Otherwise, it works perfectly. Good work!
Any chance either of the first two points will be fixed soon? This
would leave me with only one inelegant hack (two if calling MIDL
counts), and an otherwise tolerable build process.
Thanks,
--
gmt
"It does not take a majority to prevail ... but rather an irate,
tireless minority, keen on setting brushfires of freedom in the
minds of men." --Samuel Adams, Patriot
[View Less]
Hello Wine developers,
The one program holding back linux adoption in my lab is the application
Kaleidgraph. Kaleidagraph is a graphing application that is avaibable for
Windows and Macintosh.
I've been trying to use Kaleidgraph with wine (wine-20021219) without a
windows installation on the computer. The installation works pretty well:
Kaleigraph is installed, only the installer does not exit cleanly but not
until it asks about displaying the readme file.
Running Kaleidagraph does give …
[View More]quite a few problems. The problems seem to
arise from bugs and not missing features in wine. One bug for example is,
that almost all menu entries are listed twice ("File Edit Gallery ... Windows
Edit Gallery ... Windows Help").
I'd like to help in making this program run by testing with the CVS version
and submitting bugs. However, I think it would be easier if someone more
experienced looks at the program first and irons out the biggest problems,
because they are instantly obvious when you try to run the program with wine.
There is a demo version of Kaleidagraph that can be downloaded for free from
www.kaleidagraph.com.
Best regards, Jos
[View Less]
Hi, I think this code in menu.c,
BOOL WINAPI SetMenuItemInfoA(HMENU hmenu, UINT item, BOOL bypos,
const MENUITEMINFOA *lpmii)
{
if ((lpmii->fType & (MF_HILITE|MF_POPUP)) || (lpmii->fState)) {
/* QuickTime does pass invalid data into SetMenuItemInfo.
* do some of the checks Windows does.
*/
WARN("Bad masks for type (0x%08x) or state (0x%08x)\n",
lpmii->fType,lpmii->fState );
return FALSE;
}
....
is buggy, …
[View More]because it checks the type and state even when fMask doesn't
indicate that these fields are being used. It was added by Marcus
Meissner at LinuxTag in 2001 which is why I'm confused, the bug I'm
playing with/learning how to debug with is a regression and didn't exist
a few months ago, yet that code has been in Wine for some time.
Could somebody more experienced than me please look over the description
of the MENUITEMINFO struct:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinU…
and the SetMenuItemInfo call:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinU…
.. and tell me if I'm reading this situation correctly? I don't think it
should be returning false like this when fMask is 6, ie MIIM_ID |
MIIM_SUBMENU.
It'd only take a minute, promise :)
--
Mike Hearn <m.hearn(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center
[View Less]
Hi again,
----Message d'origine----
>Sujet: Re: Re: html browser for wine (khtml)
>De: Mike Hearn <m.hearn(a)signal.qinetiq.com>
>A: fenix(a)club-internet.fr
>Copie à: m.hearn(a)signal.dera.gov.uk, hetz(a)witch.dyndns.org,
>Date: 10 Jan 2003 09:47:41 +0000
>
>> As i know, khtml support most of the IE-isms (for compatibility, try to actve "IE support" in konqueror).
>> And for ActiveX, it must be simply supported by a khtml plugin (as crossover plugin do)
&…
[View More]gt;
>If only it were that simple. Rather ironically the thing that led to me Wine in the first place was that
>I needed to use features of an ActiveX control that were only available under IE.
Same problem here :)
> Although it would also (in theory)
>work in Mozilla or Konq as well, in practice they didn't support rich enough plugin interfaces for host scripting
>merge (where the plugin hooks into the browsers script interpreter and partially merges them together). Hence I now
>sometimes need to use IE under Linux.
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kparts/browserextension.h?…
-> LiveConnectExtension is for scripting Interface (kjs and JAVA support use it so it will be sufficient for ActiveX/ActiveScript)
(I have played with it a long time ago for a mini-basic scripting support)
>There are lots of IEisms that I doubt Konq replicates. ActiveX controls are sometimes a lot more complex than just
>displaying some controls on a page, they can actually integrate with IE to quite an impressive extent.
maybe but all ActiveX i have seen are only embeded plugins or code who:
- sometimes modify html rendering (ex: embeding directx panel, ...)
- do some windows calls
And i don't see what you cannot do with konq plugins.
>For instance:
>
>- DirectX filters
hmm, problem here, DirectShow and DirectMedia are not supported by wine yet ( it's at end on my todo list :) ).
>- DHTML Behaviours
if you talk by unsupported specific IE-DHTML behaviors by kthml ... we have to see if we can easily extend khtml parser without forking kthml code (i haven't see how parser interact with plugins)
Maybe asking khtml people if its possible integrating more IE-isms compat in kthml ...
>- ActiveScript (needs a vbscript interpreter as well as a JS interpreter)
>- ActiveX data binding
>- .NET integration
.NET integration is difficult because it can use SOAP and somes XMLs stupid things :(
>and so on. I expect upstream khtml could get 80% of the way there, but the remaining 20% would require tight
>integration with Wine and some extensive code changes.
>--
>Mike Hearn <m.hearn(a)signal.qinetiq.com>
>QinetiQ - Malvern Technology Center
>
Raphael
[View Less]
Hi,
----Message d'origine----
>Sujet: Re: html browser for wine (khtml)
>De: Mike Hearn <m.hearn(a)signal.qinetiq.com>
>A: hetz(a)witch.dyndns.org
>Copie à: dpaun(a)rogers.com, wine-devel(a)winehq.com
>Date: 10 Jan 2003 09:14:54 +0000
<snip>
>About duplication - I think it's probably most likely that the best course would be
>to copy the KHTML source into the Wine tree, because I'd expect modifications would
>be needed in order to support all the IEisms …
[View More]that will crop up in regular usage of
>the WebBrowser control. KHTML out of the box won't, and never will support ActiveX,
>IE specific markup or any of the other proprietary stuff MS threw in for fun during
>the browser wars. The KDE team would rightly reject such patches from being integrated
>into upstream.
As i know, khtml support most of the IE-isms (for compatibility, try to actve "IE support" in konqueror).
And for ActiveX, it must be simply supported by a khtml plugin (as crossover plugin do)
>thanks -mike
>--
>Mike Hearn <m.hearn(a)signal.qinetiq.com>
>QinetiQ - Malvern Technology Center
Raphael
[View Less]
Hi,
Yesterday, Apple released their web browser - Safari. The license is LGPL and
the code is based on KDE's KHTML rendering engine.
Whats the difference? now you don't need QT, so license wise - it's kosher ;)
Thanks,
Hetz
On January 10, 2003 01:14 am, Glen Kaukola wrote:
> All they have is C++ code. So maybe I should go with my
> original plan of compiling stuff with visual studio and seeing if it
> runs under wine. Or do you have any other suggestions?
Compiling stuff with visual studio is a first step. But it should be
very simple to do a Makefile for the examples, how many files do you
have in one example?
Here is an example Makefile that you can use under mingw:
(let me know if it doesn't work, …
[View More]I just typed it inline here, no testing)
>--------------- cut here ------------------------<
CC = gcc # change this to winegcc under Wine
CXX = g++ # change this to wineg++ under Wine
RC = windres # change this to wrc under Wine
# There six lines will change between examples
TARGET = sample1.exe #name of the executable
SRCS = file1.cpp file2.cpp ...
RSRC = res1.rc res2.rc ...
# If you need to add defines, add them to CPPFLAGS
# CPPFLAGS, INCDIRS, LIBDIRS, and LIBS may change between examples
CPPFLAGS = # add stuff here like -D_WIN32_IE=0x0400
CFLAGS = -mno-cygwin -W -Wall -g -gstabs+ -fno-exceptions -fno-rtti
LDFLAGS = -mno-cygwin -mwindows
INCDIRS = # add stuff there like -I../include
LIBDIRS = # add stuff like -L../lib
LIBS = -lcomctl32 # we'll need to add more libs in here for sure
OBJ = $(SRCS:.c=.o) $(RSRC:.c=.o)
%.o : %.rc
$(RC) $(CPPFLAGS) $< $@
%.o : %.cpp
$(CXX) $(CFLAGS) $(CPPFLAGS) $(INCDIRS) -c -o $@ $<
%.o : %.c
$(CC) $(CFLAGS) $(CPPFLAGS) $(INCDIRS) -c -o $@ $<
$(TARGET): $(OBJS)
$(CXX) $(LDFLAGS) $(LIBDIRS) $(LIBS) -o $@ $(OBJS)
# A few nice targets
all: $(TARGET)
clean:
rm -f $(TARGET) $(OBJS)
>--------------- cut here ------------------------<
It's not hard, just look in the .dsp project to see what you
need to put in these variables.
--
Dimi.
[View Less]