Re: html browser for wine (khtml)
Well, last time the talking here was that due to QT license, KHTML couldn't be used, and now with the Safari you don't need any QT (you can use other GUI kits around)... Actually Ender was de-Qting KHTML at some point, are you still around Ender? I haven't seen the code but I expect you can forget about Safari - iirc it's been integrated with Quartz which is of course a proprietary Apple system only. Seeing as they were ranting about speed, I doubt they'll have imposed the overhead of a graphics layer abstraction system. 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 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. I don't know how much progress Ender made, it might be worth emailing him to find out. thanks -mike -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: Re: html browser for wine (khtml)
Hi, Message d'origine Sujet: Re: html browser for wine (khtml) De: Mike Hearn [EMAIL PROTECTED] A: [EMAIL PROTECTED] Copie à: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: 10 Jan 2003 09:14:54 + 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 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 [EMAIL PROTECTED] QinetiQ - Malvern Technology Center Raphael
Re: Re: html browser for wine (khtml)
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) 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. 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. 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. For instance: - DirectX filters - DHTML Behaviours - ActiveScript (needs a vbscript interpreter as well as a JS interpreter) - ActiveX data binding - .NET integration 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 [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: Wine, Mozilla IE ?
http://winehq.org/news/?view=147#IWebBrowser%20Status Some of the discussion is summed up there. Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms. Alexandre, what's the reasoning behind the no C++ rule? On Fri, 2003-01-10 at 10:26, Juan Rey Saura wrote: Hi ! I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great. Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ). Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation? -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: Re: Re: html browser for wine (khtml)
Hi again, Message d'origine Sujet: Re: Re: html browser for wine (khtml) De: Mike Hearn [EMAIL PROTECTED] A: [EMAIL PROTECTED] Copie à: [EMAIL PROTECTED], [EMAIL PROTECTED], Date: 10 Jan 2003 09:47:41 + 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) 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?rev=1.94content-type=text/x-cvsweb-markup - 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 [EMAIL PROTECTED] QinetiQ - Malvern Technology Center Raphael
Re: Wine, Mozilla IE ?
Thank you ! And excuse me! I was looking for some information about that in the mailing list archive and in the WineWeekly News but probably I did not pay enough attention. Mike Hearn wrote: http://winehq.org/news/?view=147#IWebBrowser%20Status Some of the discussion is summed up there. Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms. Alexandre, what's the reasoning behind the no C++ rule? On Fri, 2003-01-10 at 10:26, Juan Rey Saura wrote: Hi ! I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great. Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ). Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation?
Re: getting started
Dimitrie O. Paun wrote: 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, I just typed it inline here, no testing) Well I know at least the basics of Makefiles already, on linux anyhow. I'm thinking I can easily come up with one for each of the sample programs in my books. I guess I was confused by the suggestion to use the Makefiles from my book, thinking that there would be something special about them. I'm not very familiar with windows development, so it's an honest mistake. It seems studio doesn't even use makefiles though. By the way, I feel terrible about it, hehe, but I went out and got visual c++. So I guess I'll be testing any executables I produce with it as well as going the other route with mingw. So now unless I have any unforseen problems, you probably won't hear from me for a while until I find something that doesn't work. Thanks for taking the time to help me get started.
Wine, Mozilla IE ?
Hi ! I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great. Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ). Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation?
Re: Wine, Mozilla IE ?
Mike asked me to e-mail a status report on my KHTML work, so here it is :) I've been too busy lately (job hunting mostly, although I've also been sick and bedridden lately) to do any more work on it, and I was really waiting for Alexandre to comment on my question about C++ before going any further... I havn't seen a reply yet tho. The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it. It is currently quite MS html compatible, and my CHM viewer seems to have few problems rendering HtmlHelp pages using the KHTML/KJS functionality. Unlike Gecko, which is too 'standards compliant'... eg, it deliberatly doesn't implement any of the IE specific functionality. The other issue I need to look into is where each part of IE functionality need to go. Implementing IWebBrowser is easy enough from my current work, however that is only the very top of the iceburg. The more important issue is to get all the various parts in the right dlls (shdocvw, shdoclc, jscript, ecetra). Many programs that embed IE use and/or subclass a large number of functions - mostly undocumented - from these dlls, as opposed to using IWebBrowser itself. There is also the problem of res:// inclusion of HTML templates embedded in shdocvw, ecetra. This is, btw, another reason that gecko isn't very well suited. It would require a lot more work to butcher gecko (simply because of it's size and complexity) into these stub dlls, than it would to do so to KHTML/KJS. Either way, it's a lot of work that unfortunatly I don't have all that much time to do at the moment. Hopefully my job hunting will calm down soon, and I will have time to clean up the code to a state where I can at least post it for other people to work on... then again, if it calms down it means I've FOUND a job... so it could work both ways :) - Ender On 10 Jan 2003, Mike Hearn wrote: Date: 10 Jan 2003 10:39:01 + From: Mike Hearn [EMAIL PROTECTED] To: Juan Rey Saura [EMAIL PROTECTED] Cc: Wine development mailing list [EMAIL PROTECTED] Subject: Re: Wine, Mozilla IE ? http://winehq.org/news/?view=147#IWebBrowser%20Status Some of the discussion is summed up there. Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms. Alexandre, what's the reasoning behind the no C++ rule? On Fri, 2003-01-10 at 10:26, Juan Rey Saura wrote: Hi ! I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great. Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ). Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation? -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: Wine, Mozilla IE ?
Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms. Alexandre, what's the reasoning behind the no C++ rule? BTW: if someone follows the kfm-devel (Konqueror's) lists, then you can see that people are trying to compile it under windows... http://lists.kde.org/?l=kfm-develr=1w=2 Thanks, Hetz
Possible bug?
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, 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/WinUI/WindowsUserInterface/Resources/Menus/MenuReference/MenuStructures/MENUITEMINFO.asp
and the SetMenuItemInfo call:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources/Menus/MenuReference/MenuFunctions/SetMenuItemInfo.asp
.. 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 [EMAIL PROTECTED]
QinetiQ - Malvern Technology Center
Kaleidagraph demo
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 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
Re: Kaleidagraph demo
I'm downloading it now to take a look (until I get a response back on the menu bug I don't have much to do atm :), but I suggest you upload the trial exe to a website somewhere if you want people to have a look, I went through the registration routine but most others won't bother. Running Kaleidagraph does give quite a few problems. Unless all the issues are extremely obvious, you might want to list them. I have no idea how to work graphing apps for instance, so the testing I can do is extremely limited. -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: widl patch
On Wednesday 08 January 2003 02:53 pm, Ove Kaaven wrote: I've been wondering if perhaps MSVC-type __try/__except support can be done on gcc by taking advantage of gcc's support for nested functions. I have a prototype of this and I think it's going to work. Patches (or at least RFC's) should be forthcoming -- gmt If everyone is thinking alike then somebody isn't thinking. --George S. Patton
Re: Clean up OSS_Wave{In,Out}Init
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 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
dx8 Patches - Question
Just a question, I noticed some of the dx8 patches are not applied - Is it due to the Chrismas backlog where Alexander took a very well deserved break, or because they have slipped through the cracks (or are there problems with them)? Will it help to resubmit them based off the current cvs since there were about 4 chained together each based off the previous one? Jason
Re: Wine, Mozilla IE ?
Dan Kegel wrote: With gcc 3.2 and later, shared libraries produced by g++ will have a stable ABI, and different machines (with different versions of gcc = 3.2) will produce compatible shared libraries. I forgot to mention: this also means that you can mix and match shared libraries produced by *other* c++ compilers, not just gcc! See http://www.linuxbase.org/spec/refspecs/ http://www.codesourcery.com/cxx-abi/ http://www.armdevzone.com/EABI/CppABI.html http://gcc.gnu.org/gcc-3.2/c++-abi.html http://www.intel.com/software/products/compilers/clin/clinux.htm and, for a bit of solaris history wrt c++ abis, http://forte.sun.com/s1scc/articles/CC_abi/CC_abi.html -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Wine, Mozilla IE ?
Mike Hearn wrote: Alexandre, what's the reasoning behind the no C++ rule? I don't know the particulars, but I do know that g++'s ABI only very recently stabilized. c++ shared libraries are Not A Good Idea with any version of gcc prior to 3.2 because shared libraries built on one machine might not work with shared libraries build on another machine. With gcc 3.2 and later, shared libraries produced by g++ will have a stable ABI, and different machines (with different versions of gcc = 3.2) will produce compatible shared libraries. Debian 3.0 still uses an older version of gcc, but Debian Unstable is now transitioning to gcc 3.2 or so, I think. Once that's done, there should be little in the way of using c++ shared libraries in Linux. (There was one little ABI tweak between 3.2 and 3.3, and there may be more later, but they probably won't break many apps.) - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Wine, Mozilla IE ?
On Fri, 10 Jan 2003, Dan Kegel wrote: [...] I don't know the particulars, but I do know that g++'s ABI only very recently stabilized. Isn't that a contradiction in terms? [...] (There was one little ABI tweak between 3.2 and 3.3, and there may be more later, but they probably won't break many apps.) That too seems incompatible with something declared 'stable'. Not that I have anything against C++, I like OO programming. But these g++ compatibility issues have been like a cold shower. rant class=my opinion only From the point of vue of an ISV, distributing a Wine binary is already enough trouble with the C library changing their internal implementation (which of course they are absolutely free to do since it's *internal*) and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis... Well, I guess ISVs could always compile these libraries with Visual C++ and ship them as Windows dlls and thus benefit from a stable and Wine compatible ABI... /rant -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
Re: wine/dlls/comcat regsvr.c comcat_main.c
On January 10, 2003 12:48 am, John K. Hohm wrote:
+CLSID const *clsid;/* NULL for end of list */
[...]
+{ NULL } /* list terminator */
Why not terminate the list with a NULL pointer to the struct instead,
it's simpler and more idiomatic...
--
Dimi.
Re: Kaleidagraph demo
On Friday 10 January 2003 17:17, Mike Hearn wrote: I'm downloading it now to take a look (until I get a response back on the menu bug I don't have much to do atm :), but I suggest you upload the trial exe to a website somewhere if you want people to have a look, I went through the registration routine but most others won't bother. Here it is: http://137.224.129.22/KG35WINDEMO.EXE Unless all the issues are extremely obvious, you might want to list them. I have no idea how to work graphing apps for instance, so the testing I can do is extremely limited. There are quite a few things that cause the app to crash or draw windows in a funny way. Once the app is slighlty useable, I can list more bugs.
Re: Wine, Mozilla IE ?
Francois Gouget wrote: On Fri, 10 Jan 2003, Dan Kegel wrote: (There was one little ABI tweak between 3.2 and 3.3, and there may be more later, but they probably won't break many apps.) That too seems incompatible with something declared 'stable'. Not that I have anything against C++, I like OO programming. But these g++ compatibility issues have been like a cold shower. Yes, indeed. But things are looking *much* better. As I mentioned in my links, there's now an ABI standard that all c++ compilers can conform to, and at least Intel, SGI, and Gnu are all trying very hard to conform to it. gcc 3.0 was the first gcc to try to conform; gcc 3.2 fixed a bunch of conformance problems; gcc 3.3 fixed a couple tiny ones that became evident after 3.2 was released. rant class=my opinion only From the point of vue of an ISV, distributing a Wine binary is already enough trouble with the C library changing their internal implementation (which of course they are absolutely free to do since it's *internal*) and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis... Well, I guess ISVs could always compile these libraries with Visual C++ and ship them as Windows dlls and thus benefit from a stable and Wine compatible ABI... /rant The g++ ABI will *not* change on a regular basis. It is rapidly converging on the portable C++ ABI shared by several vendors, and defined in a standards document. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Kaleidagraph demo
There are quite a few things that cause the app to crash or draw windows in a funny way. Once the app is slighlty useable, I can list more bugs. Yeah, I just tried it. Clearly not happy at all. I'm getting lots of errors saying it didn't call BeginPaint in a WM_PAINT handler, which iirc is a bug in the app? I think you're always supposed to call BeginPaint when you receive a WM_PAINT message at some point (unless it's actually a bug in the wine controls library). It doesn't run at all with the latest version of CrossOver, with the Dec 19th release it runs but with lots of nasty bugs. I don't see the menu duplication error though. When I got that automated email from Synergy I replied telling them about Wine, maybe they'd be willing to help it run. Oh well, here's to dreaming :) BTW I am very much a newbie Wine developer so I can probably give hints only. -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: Wine, Mozilla IE ?
On Fri, 10 Jan 2003, Dan Kegel wrote: [...] The g++ ABI will *not* change on a regular basis. It is rapidly converging on the portable C++ ABI shared by several vendors, and defined in a standards document. That's good news. especially if multiple vendors use the same ABI it seems all the more likely to actually be stable. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Readfile on a duplicated pipe hangs
Hallo,
Marcus sent me patches that made Altera quartus install. Thanks.
Now running the package hangs in the way it communicates with created
processes.
Here is what happens in my understanding:
M: Masterprocess C: Childprocess
M: CreatePipe - handle_read + handle_write
M: DuplicateHandle handle_read - handle_read_dup
M: CloseHandle (handle_read)
M: Call CreateProcessA with handle_write as hstderr
M: Return Createprocess
M: CloseHandle (handle_write)
M: Call Readfile (handle_read_dup)
C: initializes, executes and exit
M: Return Readfile retval=0001
M: Endless loop of Call Readfile (handle_read_dup) retval=0001
MSDN says, that ReadFile should fail on an anonymous pipe, if the othe end
has close.
With following patch, the application starts up. Feedback welcome.
Index: wine/server/pipe.c
===
RCS file: /home/wine/wine/server/pipe.c,v
retrieving revision 1.24
diff -u -r1.24 pipe.c
--- wine/server/pipe.c 30 May 2002 20:12:58 - 1.24
+++ wine/server/pipe.c 10 Jan 2003 20:28:43 -
@@ -141,6 +141,13 @@
static int pipe_get_info( struct object *obj, struct get_file_info_reply *reply, int
*flags )
{
+struct pipe *pipe = (struct pipe *)obj;
+assert( obj-ops == pipe_ops );
+if (!pipe-other)
+{
+set_error( STATUS_PIPE_BROKEN );
+return -1;
+}
if (reply)
{
reply-type= FILE_TYPE_PIPE;
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine, Mozilla IE ?
On January 10, 2003 06:45 am, Ender wrote: The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it. Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff? If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree. There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)). -- Dimi.
Re: Wine, Mozilla IE ?
On January 10, 2003 02:07 pm, Francois Gouget wrote: and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis... A valid concern. But it should be a configure option (--with[out]-khtml), so they can easily disable if need be. Anyway, people should not need to ship an embedded Wine. With a bit of luck, we will ship a 0.9 this year, (and hopefully 1.0), it should be like glibc soon :). Besides, the interface to _Wine_ is always C, it doesn't matter that Wine uses C++ internally. If there are compatibility concerns, we just statically link -lstd++, and be done with it. -- Dimi.
Re: Wine, Mozilla IE ?
Why don't look at the stuff Apple made for their khtml wrapper? They made two components to interact with khtml. One javascript wrapper (JavascriptCore) and another component containing some sort of QT wrapper called WebCore. The license of WebCore looks LGPL compatible (not 100% sure), so perhaps it is possible to reuse the stuff they made. When khtml gets an update they can plug it in this framework and it should work. (theoraticly) On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote: On January 10, 2003 06:45 am, Ender wrote: The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it. Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff? If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree. There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).
Re: Help with /?? stuff
Alberto Massari wrote: You can read from the MSDN page (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/movefileex.asp) what is the format used by MoveFileEx. That string is a NULL-separated list of pairs of files, where the first one is the source and the second is the target of the move operation (if the target is missing, the file should be deleted). Yes, that's the definition of REG_MULTI_SZ. Unfortunetly, if you delete a file, and then perform more delayed operations, the result is a series of NULL terminated strings, followed by an empty string (which is the REG_MULTI_SZ agreed end of strings mark), followed by more strings. This means that MS is misusing the REG_MULTI_SZ type with something that is the wrong format. No big deal, just an observation. I guess Wine is converting the NULL into \?? to be able to store it as a string. You guessed wrong. The leading \?? is there under both Wine and Windows 2000, and in both cases there is ALSO a NULL. As neither Wine nor Windows 2000 then accepts that as a valid path, I'll just remove it. I was just wondering whether anyone knows why Windows 2000 puts that extra stuff in (it's obvious why wine does that - to be compatible). BTW, do you need any help on this task? Need is a strong term. I can complete the task on my own, but your help will be most welcome (in other words, if there is another aread of Wine that needs your attention and noone seems to be working on, that would be a better use of everyone's time). If you want to help with wineboot, I think the best place to start is with the win.ini processing, and then to port Andy's function to run whole run keys to the new prog. If you do decide to help with wineboot, please email me in private when starting to work on each activity, to prevent competition on writing stuff in. Here is an excerpt of the doc: I guess this is one of those cases where the official MS docs don't 100% tell you everything you need to know to reimplement. Thank goodness these are very rare and far apart. Thank goodness even more that the cases where they don't tell you everything you need to know in order to use are even rarer. The PendingFileRenameOperations value is of type REG_MULTI_SZ. Each rename operation stores a pair of NULL-terminated strings. The system uses these registry entries to complete the operations at restart in the same order that they were issued. For example, the following code fragment creates registry entries that delete szDstFile and rename szSrcFile to be szDstFile at restart: MoveFileEx(szDstFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT); MoveFileEx(szSrcFile, szDstFile, MOVEFILE_DELAY_UNTIL_REBOOT); The system stores the following entries in PendingFileRenameOperations: szDstFile*\0\0* According to the REG_MUTLI_SZ definition, that would have meant the end of the list of strings. IMHO, storing these values in REG_BINARY would have been better (and would have not changed the code one little bit, mind you). szSrcFile\0szDstFile\0\0 Again, actually looking at the keys with a registry editor reveals that a \??\ is prepended to each one of these. If anyone has any different experience, please let me know, but it is clear from the MoveFileExW code that whoever implemented that found the same thing when they (he? Are there any women on the Authors list?) looked at the registry. Alberto Shachar
Re: Wine, Mozilla IE ?
On January 10, 2003 05:15 pm, Roderick Colenbrander wrote: Forgot to include an url to the safari developer page containing the usefull source code. Funny thing is, you forgot the second time as well... :) -- Dimi.
Re: Wine, Mozilla IE ?
Forgot to include an url to the safari developer page containing the usefull source code. I rechecked the license of the qt wrapper (kwq) and it looks a lot like a BSD license. It also seems possible to easily compile the wrapper to work on for example Linux. (only new makefiles are needed) I hope this helps, Roderick Colenbrander On Friday 10 January 2003 21:57, Roderick Colenbrander wrote: Why don't look at the stuff Apple made for their khtml wrapper? They made two components to interact with khtml. One javascript wrapper (JavascriptCore) and another component containing some sort of QT wrapper called WebCore. The license of WebCore looks LGPL compatible (not 100% sure), so perhaps it is possible to reuse the stuff they made. When khtml gets an update they can plug it in this framework and it should work. (theoraticly) On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote: On January 10, 2003 06:45 am, Ender wrote: The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it. Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff? If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree. There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).
Windows 2000 conformance test update
Here are three updates for the status page. I think user32/sysparams passed
for me previously.
C:\winetestskernel32_test.exe path
path.c:514: Test failed: GetLongPathNameA: wrong return code, 97 instead of
42
path.c:881:TMP=C:\DOCUME~1\davidm\LOCALS~1\Temp
path.c:892:TMP=C:\WINNT
path.c:902:TMP=C:\
path.c:912:TMP=C:
path: 1730 tests executed, 0 marked as todo, 1 failure.
C:\winetestsurlmon_test generated
generated: 4 tests executed, 0 marked as todo, 0 failures.
C:\winetestsuser32_test sysparams
sysparams.c:184:testing SPI_{GET,SET}BEEP
sysparams.c:306:testing SPI_{GET,SET}MOUSE
sysparams.c:374:testing SPI_{GET,SET}BORDER
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=BorderWidth, testValue=1, value=
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=BorderWidth, testValue=0, value=
sysparams.c:139: Test failed: Missed a message: change_counter=2
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=BorderWidth, testValue=7, value=
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=BorderWidth, testValue=20, value=
sysparams.c:406:testing SPI_{GET,SET}KEYBOARDSPEED
sysparams.c:139: Test failed: Missed a message: change_counter=2
sysparams.c:440:testing SPI_ICONHORIZONTALSPACING
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=IconSpacing, testValue=101, value=
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=IconSpacing, testValue=32, value=
sysparams.c:480:testing SPI_{GET,SET}SCREENSAVETIMEOUT
sysparams.c:515:testing SPI_{GET,SET}SCREENSAVEACTIVE
sysparams.c:555:testing SPI_{GET,SET}KEYBOARDDELAY
sysparams.c:590:testing SPI_ICONVERTICALSPACING
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=IconVerticalSpacing, testValue=101, value=
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=IconVerticalSpacing, testValue=32, value=
sysparams.c:635:testing SPI_{GET,SET}ICONTITLEWRAP
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=IconTitleWrap, testValue=1, value=
sysparams.c:170: Test failed: Wrong value in registry: subKey=Control
Panel\Desktop, valName=IconTitleWrap, testValue=0, value=
sysparams.c:670:testing SPI_{GET,SET}MENUDROPALIGNMENT
sysparams.c:707:testing SPI_SETDOUBLECLKWIDTH
sysparams.c:738:testing SPI_SETDOUBLECLKHEIGHT
sysparams.c:770:testing SPI_SETDOUBLECLICKTIME
sysparams.c:817:testing SPI_SETMOUSEBUTTONSWAP
sysparams.c:880:testing SPI_{GET,SET}DRAGFULLWINDOWS
sysparams.c:915:testing SPI_{GET,SET}WORKAREA
sysparams.c:953:testing SPI_{GET,SET}SHOWSOUNDS
sysparams.c:997:testing SPI_{GET,SET}DESKWALLPAPER
sysparams: 318 tests executed, 0 marked as todo, 12 failures.
Re: dx8 Patches - Question
Ann and Jason Edmeades [EMAIL PROTECTED] writes: Just a question, I noticed some of the dx8 patches are not applied - Is it due to the Chrismas backlog where Alexander took a very well deserved break, or because they have slipped through the cracks (or are there problems with them)? Will it help to resubmit them based off the current cvs since there were about 4 chained together each based off the previous one? Most likely they slipped through the cracks; I may still have them in my queue, but it never hurts to resubmit. And especially in an area that has been undergoing many changes, I always prefer to apply an up-to-date patch than a 2 weeks old one. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/dlls/comcat regsvr.c comcat_main.c
Quoting Dimitrie O. Paun [EMAIL PROTECTED]:
On January 10, 2003 12:48 am, John K. Hohm wrote:
+CLSID const *clsid;/* NULL for end of list */
[...]
+{ NULL } /* list terminator */
Why not terminate the list with a NULL pointer to the struct instead,
it's simpler and more idiomatic...
It is because I am using a list of structures, not a list of pointers to
structures. How would you create a static list of pointers to structures,
without naming each one?
Re: Help with /?? stuff
Alberto Massari wrote: I guess Wine is converting the NULL into \?? to be able to store it as a string. Shachar Shemesh wrote: You guessed wrong. The leading \?? is there under both Wine and Windows 2000, and in both cases there is ALSO a NULL. As neither Wine nor Windows 2000 then accepts that as a valid path, I'll just remove it. I was just wondering whether anyone knows why Windows 2000 puts that extra stuff in (it's obvious why wine does that - to be compatible). I'm not sure about \??, but see this excerpt from MSDN Re CreateFile: lpFileName [in] Pointer to a null-terminated string that specifies the name of the object to create or open. In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend \\?\ to the path. For more information, see Naming a File. Windows 95/98/Me: This string must not exceed MAX_PATH characters.
Re: Wine, Mozilla IE ?
Mike Hearn [EMAIL PROTECTED] writes: Alexandre, what's the reasoning behind the no C++ rule? Some of the reasons are related to C++ itself: lack of standard ABI, large differences between compilers making it harder to write portable code. Other reasons would apply to any language: more complex build process, more external tool dependencies, harder to debug, developers need to be familiar with both languages, harder to copy code around, etc. None of these are showstoppers, but it needs a *really* good reason to overcome all of them. So far I haven't heard anything convincing enough. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dx8 Patches - Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 10 January 2003 23:47, Alexandre Julliard wrote: Ann and Jason Edmeades [EMAIL PROTECTED] writes: Just a question, I noticed some of the dx8 patches are not applied - Is it due to the Chrismas backlog where Alexander took a very well deserved break, or because they have slipped through the cracks (or are there problems with them)? Will it help to resubmit them based off the current cvs since there were about 4 chained together each based off the previous one? Most likely they slipped through the cracks; I may still have them in my queue, but it never hurts to resubmit. And especially in an area that has been undergoing many changes, I always prefer to apply an up-to-date patch than a 2 weeks old one. Hi all, i coming back just in time ;) Ok, how do you prefer: - - a huge d3d8 patch (very easy for me) - - many many little patches (h) but we have a new external need: the new x11drv/GLX stuff (know as [WINE-D3D] glx init and D3D stuff) who is the begin for GL abstraction. thanks, Raphael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+H1CBp7NA3AmQTU4RAngtAKCNnwizlB/6Iv6lwQwxcnQHEoRrdACfa3Vc BZrME9svDXLUIIlwncUaGM0= =IjwJ -END PGP SIGNATURE-
Re: [D3D8 - 1] resend of Jason Texture work + many fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 11 January 2003 01:27, Raphaël Junqueira wrote: Hi again, I forgot to say with this patch now: - - i have run successfully the NVIDIA Effects Browser 3.0 (http://developer.nvidia.com/view.asp?IO=NVEffectsBrowser_3) with many effects as Aniso (http://developer.nvidia.com/view.asp?IO=Anisotropic_Lighting) or membrane_lighting (http://developer.nvidia.com/view.asp?IO=membrane_lighting) in pure vertex shader software emulation - - Warcraf3 Demo begin to run - - SplinterCell Demo now complain about stencil support anyone have other Dx8 games demos for testing (simple if possible) ? Thanks Raphael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+H2hKp7NA3AmQTU4RAvalAJ9v746sFf+RiEGzC/Vuv1NBnprAsQCaAwdQ WiIc/yV8HbZe0iw3CwJoFuE= =He8Q -END PGP SIGNATURE-
Re: PATCH - Check/Define for vsnprintf/_vsnprintf
On January 10, 2003 07:47 pm, Steven Edwards wrote: Changelog: (porting fix for Mingw/Windows) check for vsnprintf and _vsnprintf define vsnprintf with _vsnprintf Alexandre, why don't we link with oldnames.lib in Windows, and get rid of all these tests? -- Dimi.
wine/ole error on Mingw32/MSYS
Platform is a older MSYS and GCC (3.1 something I think). I'm still getting settled in from getting tied-down so I cant test this on the latest mingw-current. only on dial-up here for now =(. Anyway any idea about this? Thanks Steven $ make gcc -c -I. -I. -I../include -I../include -DWINE_NOWINSOCK -Wall -mpreferred-sta ck-boundary=2 -gstabs+ -D__WINESRC__ -D_REENTRANT -o dx8guid.o dx8guid.c In file included from dx8guid.c:26: ../include/winuser.h:2396: unnamed fields of type other than struct or union are not allowed ../include/winuser.h:2409: unnamed fields of type other than struct or union are not allowed make: *** [dx8guid.o] Error 1 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: wine/ole error on Mingw32/MSYS
On January 10, 2003 07:53 pm, Steven Edwards wrote: $ make gcc -c -I. -I. -I../include -I../include -DWINE_NOWINSOCK -Wall -mpreferred-sta ck-boundary=2 -gstabs+ -D__WINESRC__ -D_REENTRANT -o dx8guid.o dx8guid.c In file included from dx8guid.c:26: ../include/winuser.h:2396: unnamed fields of type other than struct or union are not allowed ../include/winuser.h:2409: unnamed fields of type other than struct or union are not allowed make: *** [dx8guid.o] Error 1 Yes, Try adding: #define NONAMELESSUNION #define NONAMELESSSTRUCT Before the windows includes in files where you get this error. Look in dlls/comctl32/comctl32undoc.c for an example. -- Dimi.
Re: msvcrt: stubs for chsize, dup, dup2
--- Dimitrie O. Paun [EMAIL PROTECTED] wrote: These are needed by the inline functions in the header. ChangeLog Create stubs for chsize, dup, and dup2. I think chsize and ftruncate do the same thing so is there anyway to forward the call for chsize to ftruncate on platforms that have it? I added a configure check for this a while back because windows doesnt have ftruncate and makedep needs it. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: wine/ole error on Mingw32/MSYS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 11 January 2003 01:53, Steven Edwards wrote:
Platform is a older MSYS and GCC (3.1 something I think). I'm still getting
settled in from getting tied-down so I cant test this on the latest
mingw-current. only on dial-up here for now =(.
Anyway any idea about this?
Thanks
Steven
$ make
gcc -c -I. -I. -I../include -I../include -DWINE_NOWINSOCK -Wall
-mpreferred-sta ck-boundary=2 -gstabs+ -D__WINESRC__ -D_REENTRANT -o
dx8guid.o dx8guid.c In file included from dx8guid.c:26:
.../include/winuser.h:2396: unnamed fields of type other than struct or
union are not allowed
.../include/winuser.h:2409: unnamed fields of type other than struct or
union are not allowed
make: *** [dx8guid.o] Error 1
it seems it don't like this:
typedef struct tagMONITORINFOEXA
{
MONITORINFO DUMMYSTRUCTNAME;
CHARszDevice[CCHDEVICENAME];
} MONITORINFOEXA, *LPMONITORINFOEXA;
who become (as unnamed is active):
typedef struct tagMONITORINFOEXA
{
MONITORINFO ;
CHARszDevice[CCHDEVICENAME];
} MONITORINFOEXA, *LPMONITORINFOEXA;
h it don't seems correct to me
and if i do:
- -={$:'/cvs-src/winetest/dlls/d3d8'}=-grep DUMMYSTRUCTNAME ../../include/*
../../include/d3d8types.h:} DUMMYSTRUCTNAME;
../../include/dsdriver.h:} DUMMYSTRUCTNAME;
../../include/mmsystem.h: } DUMMYSTRUCTNAME;
../../include/mmsystem.h: } DUMMYSTRUCTNAME1;
../../include/mmsystem.h: } DUMMYSTRUCTNAME;
../../include/mmsystem.h: } DUMMYSTRUCTNAME1;
../../include/objidl.h:} DUMMYSTRUCTNAME;
../../include/winbase.h:} DUMMYSTRUCTNAME;
../../include/wingdi.h: } DUMMYSTRUCTNAME1;
../../include/wingdi.h: } DUMMYSTRUCTNAME1;
../../include/winnt.h:#define DUMMYSTRUCTNAME
../../include/winnt.h:#define DUMMYSTRUCTNAME1
../../include/winnt.h:#define DUMMYSTRUCTNAME2
../../include/winnt.h:#define DUMMYSTRUCTNAME3
../../include/winnt.h:#define DUMMYSTRUCTNAME4
../../include/winnt.h:#define DUMMYSTRUCTNAME5
../../include/winnt.h:#define DUMMYSTRUCTNAME s
../../include/winnt.h:#define DUMMYSTRUCTNAME1 s1
../../include/winnt.h:#define DUMMYSTRUCTNAME2 s2
../../include/winnt.h:#define DUMMYSTRUCTNAME3 s3
../../include/winnt.h:#define DUMMYSTRUCTNAME4 s4
../../include/winnt.h:#define DUMMYSTRUCTNAME5 s5
../../include/winnt.h: } DUMMYSTRUCTNAME1;
../../include/winnt.h: } DUMMYSTRUCTNAME2;
../../include/winnt.h: } DUMMYSTRUCTNAME3;
../../include/winnt.h:} DUMMYSTRUCTNAME;
../../include/winnt.h:} DUMMYSTRUCTNAME;
../../include/winuser.h:MONITORINFO DUMMYSTRUCTNAME;
../../include/winuser.h:MONITORINFO DUMMYSTRUCTNAME;
../../include/wtypes.h:} DUMMYSTRUCTNAME;
../../include/wtypes.idl:cpp_quote(} DUMMYSTRUCTNAME;)
only 2 typedefed_struct DUMMYSTRUCTNAME; exists and they don't compile ...
Raphael
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+H2/up7NA3AmQTU4RAgVEAJ9Yxwfx0YCwaxNwM55AvgUc3qSWoQCdErG4
OAIkzuYrr0uHgS1ypEEL+Co=
=0QTd
-END PGP SIGNATURE-
Re: [RFC] msvcrt: defines break C++ code
On January 10, 2003 01:05 pm, Alexandre Julliard wrote:
I think making them inline functions should work for now.
whineHow come I always get these assignments?/whine :)
Hey, I did just some of them (basically io.h and sys/*.h),
to preserve some form of sanity. Too much header work can
lead to violent behaviour...
This patch depends on msvcrt: stubs for chsize, dup, dup2
and it obsoletes sys/{stat,types}.h: mode_t, umask (take 2)
since I was difficult to separate them.
Also, I did not know what to do about _open(), and _sopen()
as they take variable number of arguments, so I've left them
as macros. Any ideas for these are welcome.
ChangeLog
Use inline functions instead of macros to avoid problems in C++
Inline functions respect scope, whereas macros don't.
Define umask in sys/stat.h and sys/types.h, and mode_t in sys/types.h
Index: include/msvcrt/io.h
===
RCS file: /var/cvs/wine/include/msvcrt/io.h,v
retrieving revision 1.3
diff -u -r1.3 io.h
--- include/msvcrt/io.h 18 Dec 2002 20:17:20 - 1.3
+++ include/msvcrt/io.h 10 Jan 2003 23:00:10 -
@@ -156,27 +156,30 @@
#ifndef USE_MSVCRT_PREFIX
-#define access _access
-#define chmod _chmod
-#define chsize _chsize
-#define close _close
-#define creat _creat
-#define dup _dup
-#define dup2 _dup2
-#define eof _eof
-#define filelength _filelength
-#define isatty _isatty
-#define locking _locking
-#define lseek _lseek
-#define mktemp _mktemp
+inline int access(const char* path, int mode) { return _access(path, mode); }
+inline int chmod(const char* path, int mode) { return _chmod(path, mode); }
+inline int chsize(int fd, long size) { return _chsize(fd, size); }
+inline int close(int fd) { return _close(fd); }
+inline int creat(const char* path, int mode) { return _creat(path, mode); }
+inline int dup(int od) { return _dup(od); }
+inline int dup2(int od, int nd) { return _dup2(od, nd); }
+inline int eof(int fd) { return _eof(fd); }
+inline long filelength(int fd) { return _filelength(fd); }
+inline int isatty(int fd) { return _isatty(fd); }
+inline int locking(int fd, int mode, long size) { return _locking(fd, mode, size); }
+inline long lseek(int fd, long off, int where) { return _lseek(fd, off, where); }
+inline char* mktemp(char* pat) { return _mktemp(pat); }
#define open _open
-#define read _read
-#define setmode _setmode
+inline int read(int fd, void* buf, unsigned int size) { return _read(fd, buf, size); }
+inline int setmode(int fd, int mode) { return _setmode(fd, mode); }
#define sopen _sopen
-#define tell _tell
-#define umask _umask
-#define unlink _unlink
-#define write _write
-#endif /* USE_MSVCRT_PREFIX */
+inline long tell(int fd) { return _tell(fd); }
+#ifndef MSVCRT_UMASK_DEFINED
+inline int umask(int fd) { return _umask(fd); }
+#define MSVCRT_UMASK_DEFINED
+#endif
+inline int unlink(const char* path) { return _unlink(path); }
+inline int write(int fd, const void* buf, unsigned int size) { return _write(fd, buf,
+size); }
+#endif /* USE _MSVCRT_PREFIX */
#endif /* __WINE_IO_H */
Index: include/msvcrt/sys/stat.h
===
RCS file: /var/cvs/wine/include/msvcrt/sys/stat.h,v
retrieving revision 1.6
diff -u -r1.6 stat.h
--- include/msvcrt/sys/stat.h 18 Dec 2002 20:17:20 - 1.6
+++ include/msvcrt/sys/stat.h 10 Jan 2003 19:15:38 -
@@ -106,6 +106,7 @@
int MSVCRT(_stat)(const char*,struct _stat*);
int _fstati64(int,struct _stati64*);
int _stati64(const char*,struct _stati64*);
+int _umask(int);
#ifndef MSVCRT_WSTAT_DEFINED
#define MSVCRT_WSTAT_DEFINED
@@ -127,8 +128,12 @@
#define S_IWRITE _S_IWRITE
#define S_IEXEC _S_IEXEC
-#define fstat _fstat
-#define stat _stat
+inline int fstat(int fd, struct _stat* ptr) { return _fstat(fd, ptr); }
+inline int stat(const char* path, struct _stat* ptr) { return _stat(path, ptr); }
+#ifndef MSVCRT_UMASK_DEFINED
+inline int umask(int fd) { return _umask(fd); }
+#define MSVCRT_UMASK_DEFINED
+#endif
#endif /* USE_MSVCRT_PREFIX */
#endif /* __WINE_SYS_STAT_H */
Index: include/msvcrt/sys/timeb.h
===
RCS file: /var/cvs/wine/include/msvcrt/sys/timeb.h,v
retrieving revision 1.4
diff -u -r1.4 timeb.h
--- include/msvcrt/sys/timeb.h 18 Dec 2002 20:17:20 - 1.4
+++ include/msvcrt/sys/timeb.h 10 Jan 2003 18:10:39 -
@@ -60,7 +60,7 @@
#ifndef USE_MSVCRT_PREFIX
#define timeb _timeb
-#define ftime _ftime
+inline void ftime(struct _timeb* ptr) { return _ftime(ptr); }
#endif /* USE_MSVCRT_PREFIX */
#endif /* __WINE_SYS_TIMEB_H */
Index: include/msvcrt/sys/types.h
===
RCS file: /var/cvs/wine/include/msvcrt/sys/types.h,v
retrieving revision 1.6
diff -u -r1.6 types.h
--- include/msvcrt/sys/types.h 18 Dec 2002 20:17:20 - 1.6
+++ include/msvcrt/sys/types.h 10 Jan 2003 19:15:14 -
@@ -39,6 +39,11 @@
Re: dx8 Patches - Question
Raphaël Junqueira [EMAIL PROTECTED] writes: Ok, how do you prefer: a huge d3d8 patch (very easy for me) many many little patches (h) Many small patches please g but we have a new external need: the new x11drv/GLX stuff (know as [WINE-D3D] glx init and D3D stuff) who is the begin for GL abstraction. I don't like this one; the X11 escape interface is a hack that should be used as little as possible, and export only what's absolutely necessary. We shouldn't export large structures like that one. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - Check/Define for vsnprintf/_vsnprintf
Dimitrie O. Paun [EMAIL PROTECTED] writes: Alexandre, why don't we link with oldnames.lib in Windows, and get rid of all these tests? Unfortunately there's no vsnprintf in oldnames.lib... -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - Check/Define for vsnprintf/_vsnprintf
--- Alexandre Julliard [EMAIL PROTECTED] wrote: Dimitrie O. Paun [EMAIL PROTECTED] writes: Alexandre, why don't we link with oldnames.lib in Windows, and get rid of all these tests? Unfortunately there's no vsnprintf in oldnames.lib... I think I missed something somewhere. Where is oldnames.lib? Thanks Steven __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Wine, Mozilla IE ?
Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? I brought up this very same argument when I first took on the task of porting it over.. however I as basically outvoted with doing the implementation as more of a wrapper than a true port :P off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: As it seem there is some effort going on to create a native Win32 KHTML port using Apple's WebCore wrapper system I think I will take a break on my current code and play with that a little. Personally I didn't want to have to take on the chore myself, but this whole Safari thing IS creating more intrest in non-X11/QT platforms... it definatly changes the playing field, and with the large speed and compatability merges from Safari lately my current tree is hopelessly out of date anyway :) So I think I will play with that and work on the DLL layout and COM interfaces until something eventuates... I've decided it's worth waiting to see what direction KHTML takes (portability wise) now that it is being use in a 'real' non-KDE application. There's no point rushing into a WINE-specific implementation if something more closely tied to the upstream code is released meer weeks later. Of course there still a small problem of having to seperate the code into MS compatible COM objects and DLLs... I will have to benchmark the speed impact of stubbing the MS dll's into khtml.dll/kjs.dll ecetra, instead of replicating the exports more natively. Cheers, Ender
Re: PATCH - Check/Define for vsnprintf/_vsnprintf
On Fri, 10 Jan 2003, Steven Edwards wrote: --- Alexandre Julliard [EMAIL PROTECTED] wrote: Dimitrie O. Paun [EMAIL PROTECTED] writes: Alexandre, why don't we link with oldnames.lib in Windows, and get rid of all these tests? Unfortunately there's no vsnprintf in oldnames.lib... I think I missed something somewhere. Where is oldnames.lib? It's astatic library which ships with Visual C++. You can find it in VC98\Lib The issue wrt. open and other variable argument functions may be our cue that we should really have our own oldnames.a library... -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware
Re: PATCH - Check/Define for vsnprintf/_vsnprintf
It's astatic library which ships with Visual C++. You can find it in VC98\Lib The issue wrt. open and other variable argument functions may be our cue that we should really have our own oldnames.a library... Sounds good and if it will save me from having to write more boring configure checks then I am all for it. =) Once again I think its one of those things that sounds god but I dont know how much I can help on it other then testing. Thanks Steven __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
shlwapi.dll from Wine regression tests on Windows 2000 SP3
I did a compare of windows shlwapi with WINEs shlwapi. With Windows 2000 SP3 shlwapi.dll we get - C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe clist clist: 236 tests executed, 0 marked as todo, 0 failures. C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe generated generated: 25 tests executed, 0 marked as todo, 0 failures. C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe path path.c:92: Test failed: Expected ?query=xreturn=y, but got query=xreturn=y path: 33 tests executed, 0 marked as todo, 1 failure. C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe shreg shreg.c:171: Test failed: (44,43) shreg.c:183: Test failed: (2) shreg.c:195: Test failed: (14,43) shreg.c:196: Test failed: (2) shreg.c:204: Test failed: Expected ERROR_MORE_DATA shreg.c:205: Test failed: () shreg.c:206: Test failed: () shreg.c:207: Test failed: (1,43) shreg.c:218: Test failed: (44,43) shreg.c:262: Test failed: didn't open copy shreg: 40 tests executed, 0 marked as todo, 10 failures. C:\Documents and Settings\Administrator\Desktop\test With the current WINE shlwapi on Windows 2000 we get C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe clist clist: 236 tests executed, 0 marked as todo, 0 failures. C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe generated generated: 25 tests executed, 0 marked as todo, 0 failures. C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe path fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:81: Test failed: UrlGetPartA didn't return S_OK fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:83: Test failed: UrlGetPartW didn't return S_OK path.c:87: Test failed: Strings didn't match between ascii and unicode UrlGetPar t! path.c:92: Test failed: Expected localhost, but got x#9786;ö fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:81: Test failed: UrlGetPartA didn't return S_OK fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:83: Test failed: UrlGetPartW didn't return S_OK path.c:87: Test failed: Strings didn't match between ascii and unicode UrlGetPar t! path.c:92: Test failed: Expected 21, but got x#9786;ö fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:81: Test failed: UrlGetPartA didn't return S_OK fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:83: Test failed: UrlGetPartW didn't return S_OK path.c:87: Test failed: Strings didn't match between ascii and unicode UrlGetPar t! path.c:92: Test failed: Expected foo, but got x#9786;ö fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:81: Test failed: UrlGetPartA didn't return S_OK fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:83: Test failed: UrlGetPartW didn't return S_OK path.c:87: Test failed: Strings didn't match between ascii and unicode UrlGetPar t! path.c:92: Test failed: Expected bar, but got x#9786;ö fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:81: Test failed: UrlGetPartA didn't return S_OK fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:83: Test failed: UrlGetPartW didn't return S_OK path.c:87: Test failed: Strings didn't match between ascii and unicode UrlGetPar t! path.c:92: Test failed: Expected http, but got x#9786;ö fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:81: Test failed: UrlGetPartA didn't return S_OK fixme:shell:URL_ParseUrl failed to parse Lhttp://foo:bar@localhost:21/internal. php?query=xreturn=y path.c:83: Test failed: UrlGetPartW didn't return S_OK path.c:87: Test failed: Strings didn't match between ascii and unicode UrlGetPar t! path.c:92: Test failed: Expected ?query=xreturn=y, but got x#9786;ö path: 33 tests executed, 0 marked as todo, 24 failures. C:\Documents and Settings\Administrator\Desktop\test C:\Documents and Settings\Administrator\Desktop\testshlwapi_test.exe shreg shreg.c:171: Test failed: (44,43) shreg.c:195: Test failed: (44,43) shreg.c:205: Test failed: () shreg.c:206: Test failed: () shreg.c:207: Test failed: (44,43) shreg.c:218: Test failed: (44,43) shreg.c:262: Test failed: didn't open copy shreg: 37 tests executed, 0 marked as todo, 7 failures. C:\Documents and Settings\Administrator\Desktop\test __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
