Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
On Thu, Aug 28, 2003 at 07:07:25PM +0200, Jon Bright wrote: > Alexandre Julliard wrote: > > > With a run-time check you don't have to sacrifice anything, the binary > > is still portable everywhere, but can also use MAP_TRYFIXED for better > > performance if it exists in the running kernel. > > Except that if you build it on a machine which knows about MAP_TRYFIXED > at all, the resulting binary's not likely to run on older machines... It is exteremely unlikely to run anyway due to changes in other parts of the ABI. For instance the dynamic linker in NetBSD 1.5.1 cannot load programs compiled under NetBSD current (NetBSD current can run programs compiled under 1.5.1). It is called 'backwards compatibility'. David -- David Laight: [EMAIL PROTECTED]
Errors with creating desktop icons in 20030813 release..
With the 20030813 release the following error displays to the console when I try to install mIRC 6.03: "err:ddeml:DdeConnect Done with INITIATE, but no Server window available" the mIRC install displays a dialog with: "There seems to be a problem adding mIRC icons to the Program Manager!" Other than that, mIRC seems to work fine. After a bit more testing I'm finding any app that I try to install with this release creates the same error message. Any thoughts? -- David Orriss Jr. Please email me if you want my ICQ/AIM/IM ID's.
Re: Viruses in the wine-devel archive ??
> > Should we contact that author and let him > > know he is infected, or simply remove him from the list? > > Probably remove him from the list, then inform him and ask to subscribe > if he is still interested. You need to be careful, the 'From:' in the mail is probably wrong, so you need to check the IP address reported by the first (known) MTA. I've been receiving a lot of bonce messages for this virus, and my NetBSD system isn't compromised (I'm not actually running wine!) David -- David Laight: [EMAIL PROTECTED]
Re: export variables in dlls
> Perhaps I'll contribute a bash version of winewrap soon, just for fun.
Avoid 'bash'isms, not everyone has, or even wants to run, bash.
It ought to be possible to keep to the posix shell rules.
(bash is completely broken wrt the only standard for shells)
David
--
David Laight: [EMAIL PROTECTED]
Windows API db / find APIs missing for a given app
Recently I spent some time on this again and would like anyone interested in the database to take a look and email me comments. (What's good, how it can be better, and what features could be there, but aren't) Currently the web interface consists of a few forms which do the following: 1. Compare imports or exports between two windows versions. This will output all APIs imported or exported by a dll you specify along with which version exports that API. Example: you specify wine and windows95 as windows versions. Each API will say it is exported by wine only, win95 only, or both. It is color coded in the hope of making it slightly more readable. 2. Perform general queries. This just does SQL queries based on the criteria you specify. You can query by any or all fields. 3. Find unimplemented APIs for a given program. This locates all APIs imported by a specified application and outputs the ones which are unimplemented or stubs in wine. This is broken down by dll which the app tries to import from. Red APIs are not in wine spec files while blue APIs are listed as stubs in the spec files. There are only a couple of apps listed right now. Leave the application field empty for a complete list. I intend to make the output hyperlinks which will query for all apps importing that specific API. Maybe that will help find test cases when tracking down a bug. The forms are currently at http://24.229.94.2 Unfortunately I can't keep this as a permanent location. The PC is just too slow and the scripts really hog CPU. They do lots of SQL queries. :)
Strange behavior on build
I'm having a strange behavior trying to build Wine on my machine at work
(which is a modified RH7.3 machine):
First of all, if I attempt to do a standard CVS checkout followed by a
make depend, the make depend failes with a "dlls - no such directory"
error, even though it exists.
Changing SHELL=/bin/sh to SHELL=/bin/bash in Make.rules and re-running
configure fixes this, but then I get stuck in a loop building - it looks
like the makefile starts building the dependancy "wine", then builds
"libs", then decides it needs to build "wine" to build "libs" and starts
that, then builds "libs"
I'm at a bit of a loss to explain the behavior, so does anybody have any
good suggestions?
Versions:
GNU bash, version 2.05b.0(1)-release (i586-redhat-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-redhat-linux-gnu
Linux version 2.4.20-openmosix1 (root@(none)) (gcc version 2.96 2731
(Red Hat Linux 7.3 2.96-113)) #1 Sun Jan 12 04:18:51 CST 2003
(if you would be so kind, please copy my work address of David
decimalpoint Hagood ('A'-1) aeroflex decimalpoint com since I am only
subscribed to the list on my personal email).
Re: Sync(2): oleaut32 I1 funcs
> Is there any reason for stripping out the parameter names from this file?
> They can be quite useful as a reminder for what each parameter is.
They can cause serious grief if for example:
1) they happen to match the name of a #define
2) they match the name of a global item and you have enough warnings
enabled.
> P.S. In other parts of your patch you replaced char with signed char. Is
> signed char != char?
There are systems where char == unsigned char.
If you want an 8 bit integer, you probably ought to be using int8_t
or uint8_t which a system ought to be supplying (real soon now)
in .
David
--
David Laight: [EMAIL PROTECTED]
Re: Loader fix for pathes differing by extra backslashes
> Even if windows treats these as seperate modules, then we still have a > problem, because dlopen works with unix pathes, and filenames differing > by a backslash still have the same unix path. dlopen will almost certainly do a device/inode_number check on the open file, rather than any comparison of the names. David -- David Laight: [EMAIL PROTECTED]
Re: Bidi B patch
> I'll try to find the discussion (if someone has a handy pointer - it > would be greatly apretiated), but if it turns out that it is necessary > because we use "" instead of <>, I don't think that counts ;-) I believe that the difference between "" and <> is that if you use "" the directory where the file that contains the #include is looked in before the directories specified with -I and the 'standard' places. This can make it VERY difficult to build with a local (aka hacked) copy of an include file. Also, if there are multiple files with the same name it may not be obvious which one is actually included. IMHO Using <> throughout is actually best - unless you actually really, really want the file from the directory where the including file was found. David -- David Laight: [EMAIL PROTECTED]
Re: Merge of WineX's (LGPL licensed) wininet.dll code
Hi There, This would be related to the open-ssl thing I did... Basically rather than rewriting a bunch of wininet code, I wrote a layer around the winsock stuff so that it can easily switch between ssl and non-ssl sockets.. The odd thing is in my WineX tree (where I do my development) that fixme isn't in InternetReadFile - theres now only one, and thats in InterneWriteFile... Mike McCormack - is it possible this file (internet.c) didn't get merged properly? Mike Hearn - check out the function 'InternetReadFile' at this URL and compare against your post-patched winehq version. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/wininet/internet.c?rev=1.3&content-type=text/vnd.viewcvs-markup *few minutes later* ok, so I checked out winehq cvs and applied the patch.. Mike McCormack - it looks like you merged the contents of InternetWriteFile into both InternetWriteFile and InternetReadFile.. I may be wrong (I just woke up).. The FIXME in InternetWriteFile has no bad effect, things will still work (so long as you're not using HTTPS) - but in InternetReadFile, I have my doubts. Cheers. David On Mon, 2 Jun 2003 23:32, Mike Hearn wrote: > Well, I'm spending my fun afternoon trying to get IE to install in Wine > (it breaks in a new and interesting way every time I try this). > > Before the patch, it didn't work, couldn't contact download sites. After > the patch, it still doesn't work, and I get this fixme: > > fixme:wininet:InternetReadFile This shouldn't be here! We don't support > this kind of connection anymore. Must use NETCON functions, especially > if using SSL > > Which seems a bit of a bummer, if IE6 setup needs that type of > connection I think we should still support it really.. > > I think the problem might be lack of proxy workingness. Am investigating > now. Would be nice to lift proxy details from the http_proxy variable in > future > > One last thing, the patch seemed to have a lot of whitespace no-ops, > running diff with -bB should eliminate some. > > thanks -mike -- David Hammerton TransGaming Technologies [EMAIL PROTECTED] http://www.transgaming.com/ *Let the games begin*
Re: Bidi B2 - GetCharacterPlacement order array
> >>+if (lpResults->lpOutString) > >>+for (i = 0; i < nSet && lpString[i] != 0; ++i) > >>+lpResults->lpOutString[i] = lpString[i]; > >> > >> > > > >What about a strncpy here: Be aware that strncyp() rarely DTRT, in particular: - it doesn't guarantee to zero terminate the target - it is required to zero fill the target buffer Neither of these is usually desirable. Many systems have a strlcpy() function which does what you want much more often. OTOH is the target buffer can be too short with valid data, they you need to (typically) dynamically allocate a buffer. David -- David Laight: [EMAIL PROTECTED]
Re: building a windows API database
Hi, I have attached the script I am working on for this project. It is not
finished. Currently it will ignore APIs with no name or ordinal
### simply because I haven't figured out how to handle them yet. There
seems to be a general consensus on wine-devel we don't need a MySQL
database so I am working toward a text file solution instead. I do think
MySQL could be useful though if someone made a nice interface to query the
database. Any help, comments, and suggestions are always welcome. :)
Currently this script will:
locate dlls and dump import and/or export information with dumpbin
cross reference imports in an HTML map
parse the dumped exports and try to determine the status of each API based
on entries in the wine .spec files.
If you do not have access to perl on a windows system and dumpbin (from
visual C++) I can provide sample output.
At 11:35 AM 3/25/2003 -0800, you wrote:
Hi, I am interested in your project of
having an API database.
I am building it, storing the information
in a server (MySQL), in order to retreive
from it any information about apis
and their relationship with other apis
and constants.
I don't know if you have something yet,
and would like to share with you
the project.
Greetings...
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
#!/usr/bin/perl
#
#
# Version 1.5
#
#
# Scan a specified path for dlls and cross reference imports in imports.html
# Dump all dumpbin /imports and /exports output to imports.txt and exports.txt
respectively
# Parse imports.txt and exports.txt and place output in imported_api.html and
exported_api.txt
#
#
# I am using ActiveState ActivePerl 5.8 on Windows XP
#
#
# BUGS
#
# Cannot handle spaces in directory or file names
# Errors are not reported when parsing exports
#
#
# TODO
#
# Format output in a matrix
# Possibly make format selectable on command line, HTML or matrix output
if (scalar @ARGV <=0) {
usage();
}
sub usage() {
print("Usage winapi_list.pl \n\n");
print("Available options:\n\n");
print("-p\tSpecify a path to search for dlls.\n");
print("\tUse with -d (dump) option.\n\n");
print("-d\tRequires -p option. Dumps imports or exports.\n");
print("\tPossible values are imports, exports, and all.\n\n");
print("-e\tCreate a text file containing a list of APIs\n");
print("\texported by each dll.\n\n");
print("-h\tCreate an HTML map cross referencing DLL imports.\n");
print("\tPossible values are api, noapi, and all.\n\n");
print("-b\tSpecify the path to the wine spec files and build\n");
print("\ta database of APIs and whether they are implemented\n");
print("\tin wine based on the information in the wine .spec files.\n");
print("\tThis option is not complete, and will ignore APIs with no name.\n");
}
use Getopt::Std;
getopts ("ep:h:d:b:");
if ($opt_p) {
$dir=$opt_p;
find_dlls();
}
if ($opt_d) {
if ($opt_d ne "imports" & $opt_d ne "exports" & $opt_d ne "all") {
usage();
exit 1;
}
if ($opt_d eq "imports") {
dump_imports();
}
if ($opt_d eq "exports") {
dump_exports();
}
if ($opt_d eq "all") {
dump_imports();
dump_exports();
}
}
if ($opt_h) {
if ($opt_h ne "api" & $opt_h ne "noapi" & $opt_h ne "all") {
usage();
exit 1;
}
if ($opt_h eq "api") {
generate_html();}
if ($opt_h eq "noapi") {
create_html_noapi();
}
if ($opt_h eq "all") {
generate_html();
create_html_noapi();
}
}
if ($opt_e) {
parse_exports();
}
if ($opt_b) {
build_export_database();
}
sub find_dlls() {
print("Generating a list of dlls...\n");
#foreach $dir {
push @dir,$dir;
while ($dirs=pop @dir){
$whereami=`cd`;
chomp($whereami);
chomp($dirs);
chdir $dirs;
while (<*>) {
next if ($_ =~ /dllcache/);
if (-d $_) {
push @dir,$dirs."\\".$_;
}
else {
push (@dlllist, "$_ $dirs\n") if /\.dll$/;
}
chdir $whereami;
}
print("Sorting and converting dlls to lowercase...\n");
@dlllist = map (lc, @dlllist);
@dlllist = sort @dlllist;
}
sub dump_imports {
open (STDOUT2, ">&STDOUT");
print("Dumping imports...\n");
open (STDOUT, "> imports.txt") || die "Unable to open imports.txt for writing!";
foreach $line (@dlllist) {
chomp($line);
($a,$b)=split(/\s\s+/,$line);
print STDOUT2 ("Dumping imports for $a\n");
system("dumpbin /imports $b/$a");
}
open(STDOUT, ">&STDOUT2");
}
sub dump_exports {
print("Dumping exports...\n");
open (STDOUT2, ">&STDOUT");
open (STDOUT, "> exports.txt") || die "Unable to open exports.txt for writing!";
foreach $line (@dlllist) {
chomp($line);
Re: new site nit
Jeremy Newman wrote: On Tue, 2003-03-25 at 22:02, Dimitrie O. Paun wrote: On March 25, 2003 11:48 pm, Dan Kegel wrote: It would be nice if the site recognized normal URLs without the ?page= prefix. That ought to be easy to hack up. The extra verbiage makes links posted in news articles look ugly. I've added more redirects to the site in the .htaccess file. The Following URLs work. http://docs.winehq.org http://faq.winehq.org http://www.winehq.org/download/ http://www.winehq.org/faq/ http://www.winehq.org/status/ http://www.winehq.org/howto/ http://www.winehq.org/todo/ http://www.winehq.org/screenshots/ http://www.winehq.org/news/ http://www.winehq.org/about/ Adding more is as simple as editing the .htaccess file That's great, but surely hardly anyone will end up using these unless the links from the main page point to these URLs rather than the ?page= ones? Unless they read wine-devel...
Re: Java in wine?
There are always at least two threads, because of the garbage collection which runs on a separate thread. I do not think any if the JVMs run the gc synchnonously. David Sylvain Petreolle <[EMAIL PROTECTED]To: Mike Hearn <[EMAIL PROTECTED]>, Wine Devel .fr> <[EMAIL PROTECTED]> Sent by: cc: wine-devel-admin@Subject: Re: Java in wine? winehq.com 26/03/2003 17:13 youpi youpi yay ! --- Mike Hearn <[EMAIL PROTECTED]> a écrit : > It seems that if WinVer is set to nt40, java runs happily (although > not > without issues of course). > > Uwe found it was due to threading some time ago, I think wine stores > something at the wrong place. I still get warnings about stack > guards, > but they don't seem to cause issues. even when running hello world or CUI class ? :) > Next problem - java appears to use DirectDraw? It wipes out the > screen > contents in the same way QuickTime did when using DirectDraw, which > obviously gets in the way of working with the app :) > > More debugging needed > > = Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Java in wine?
Have you tried the IBM JRE? David Mike Hearn <[EMAIL PROTECTED]To: Dan Kegel <[EMAIL PROTECTED]> netiq.com>cc: [EMAIL PROTECTED], Wine Devel Sent by: <[EMAIL PROTECTED]> [EMAIL PROTECTED]Subject: Re: Java in wine? inehq.com 20/03/2003 16:50 > What version of Java does the app require? Unfortunately 1.4 > I wonder if perhaps some older Sun JREs run better > on Wine than hotspot does. I haven't tried any, but > who knows, it might be worth trying. The 1.2 version at least starts, but apparently it's not sufficient for this app. And I thought java was supposed to make stuff more portable :/ > - Dan -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
Re: Java in wine?
I tried this quite a while ago, and had all manner of problems with threading. Now lots of work has happened since then, and it is possible that it now works, but it does make extensive use of the threading APIs. Maybe getting the JVM to work would be a good test suite for those APIs (if we knew which it used). David Mike Hearn <[EMAIL PROTECTED]To: [EMAIL PROTECTED] netiq.com>cc: Sent by: Subject: Java in wine? [EMAIL PROTECTED] inehq.com 20/03/2003 11:28 Hi, Perhaps a bit offtopic, but my company has asked me to try and get a desktop java app we use/are developing here running under Linux. You'd think, being written in Java, that it'd just be a case of installing the JVM and running it. Unfortunately, because Java is rather poor at desktop apps, they've used a load of windows extensions via JNI to try and make it integrate better. That means, the only solution is probably to run a JVM under Wine (short of rewriting all the native code, which they don't want to do). Now, I tried the Sun JRE, and it wasn't happy. I expect HotSpot does some wierd stuff under the covers. So I'm wondering if anybody has walked this road before, and if there are any other JVMs that might work better under Wine? thanks -mike -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
Re: (Mis)using threads
Sylvain Petreolle wrote: It does, see the nice(1), renice (8) commands and get/setpriority(2). would work. But Linux doesn't allow a non-root process to increase its scheduling priority (and of course people shouldn't run Wine as root), so it mostly seemed to just be an exercise in futility, and that's why I think nobody has bothered. And I don't expect this toimprove... Hmmm ... it seems to me that's exactly what they say: From the renice man page: Users other than the super-user may only alter the priority of processes they own, and can only monotonically increase their ``nice value'' within the range 0 to PRIO_MAX (20). (This prevents overriding administrative fiats.) The super-user may alter the priority of any process and set the priority to any value in the range PRIO_MIN (-20) to PRIO_MAX. BUGS Non super-users can not increase scheduling priorities of their own pro cesses, even if they were the ones that decreased the priorities in the first place. From the setpriority man page: The setpriority call sets the priorities of all of the specified processes to the specified value. Only the super-user may lower priorities. Do yours say anything other? David
Re: (Mis)using threads
> But Linux doesn't allow a non-root process to increase its
> scheduling priority
It ought to let you reduce it though
David
--
David Laight: [EMAIL PROTECTED]
Re: Need help with define(s)
Tony Lambregts wrote: David Fraser wrote: Tony Lambregts wrote: Wine does not have these defined anywhere. Does anyone know what they should be and where they should be defined? Not sure about REG_FORCE_RESTORE, but MinGW has the following in winnt.h #define REG_WHOLE_HIVE_VOLATILE 1 #define REG_REFRESH_HIVE 2 #define REG_NO_LAZY_FLUSH 4 OK. What include file should they be in? I presume WINNT.H as that's where they are in MSVC, mingw and cygwin. David
Re: Need help with define(s)
Tony Lambregts wrote: Following Dan's advice I thought I would try my hand at putting together a regression test for RegSaveKey(A/W). Well I kind of run into a snag with that, actualy a couple of them. The first is that the counterpart for RegSaveKey is a stub. Oh well thats OK. I can still write the test and mark it as todo. No not really. My current problem is as follows: LONG RegRestoreKey( HKEY /hKey/, LPCTSTR /lpFile/, DWORD /dwFlags/ ); dwFlags can be one of the following constatants REG_FORCE_RESTORE (This value is not supported.on windows NT) REG_NO_LAZY_FLUSH REG_REFRESH_HIVE REG_WHOLE_HIVE_VOLATILE Wine does not have these defined anywhere. Does anyone know what they should be and where they should be defined? Not sure about REG_FORCE_RESTORE, but MinGW has the following in winnt.h #define REG_WHOLE_HIVE_VOLATILE 1 #define REG_REFRESH_HIVE 2 #define REG_NO_LAZY_FLUSH 4 David
Re: Microsoft Installer compatability
Mike Hearn wrote: I should spam the list less :) http://msi2xml.sourceforge.net/ Easy way to write a Wine version of MSI? Hardly important at the moment, but might be in future. H ... I might be talking nonsense warning in advance: I had a look at this a few months back, tried to port it to Linux to fiddle with MSIs. If I'm correct in my memory, the problem was that it uses the Microsoft APIs to access the MSI files (i.e. it doesn't have its own msi file format parser), then dumps the database structure into .xml. So I guess it wouldn't be directly helpful to get Wine to do MSI as Wine doesn't have those API functions. Might be helpful for investigating stuff, seing examples of code, however. On the other hand I might be wrong so if anyone's interested they should check with the project owner David
Re: shlwapi.dll, Fix endless loop in StrPBrkW
> while (*p++ != 0x4D && p < pend);
It is best to add a continue to the above.
I remember one loop that ended up looking like:
while (...)
do {
...
} while (...);
David
--
David Laight: [EMAIL PROTECTED]
Re: Wine on Windows
Serenity wrote: You can compile it successfully on cygwin but not run it yet. If you're really interested, search the list archives and read them. If you have a specific question or a goal, say what it is, otherwise I'm not sure what to say... Well, put short, my goal is to be able to run (some) Windows executables on Windows. I'm not bothered about GUI display. My goal is actually to write code to catch certain types of calls, and then take actions based on those calls. Ta H ... if you want to just catch calls, you may find you want to create your own dlls which replace the Windows dlls and delegate calls you don't intend to catch to the original Windows dlls. What calls do you want to catch and why? At the moment Wine probably isn't going to help you here - the dlls need a lot more separating done - at least the lower level ones (user32, kernel32, ntdll etc), and although a lot of the higher level ones can compile and link, I'm not sure that anyone's tested replacing Windows dlls with them. Having said that, if you want to try something, any help in getting Wine going on Windows would be appreciated, but it takes coding skill. David
Re: Wine on Windows
Serenity wrote: Hi, Right, I've been Googling this one up, and I've found some information, but it's a few years old so I'm not sure if it's current... Has anybody had any success compiling and executing Wine on Win32? I know, it seems a bizzare concept, but I have legitament reasons to want to use Wine on Windows. There are some emails dating back to 2000 online saying it compiles on cygwin, but I'm not sure if this is still the case... Plus, ideally I'd be looking for a native port... Any directions would be great Ta Serenity You can compile it successfully on cygwin but not run it yet. If you're really interested, search the list archives and read them. If you have a specific question or a goal, say what it is, otherwise I'm not sure what to say... David
Re: [OT] Wine 0.9 config applets?
Jaco Greeff wrote: On Saturday 22 February 2003 07:08 pm, Mike Hearn scribbled on a piece of papyrus: Last time I talked to Jaco, he was busy finding work. Hopefully he'll resurface soon, maybe he has a nice surprise for us :). Yeah, Jaco, are you there? :) Alive and kicking. Way behind, but alive. Real life has set in the past month or so and I'm only starting to re-surface at this point. Somewhere between needing to put food on the table and having a new small dog things just drops on the floor.*sigh* Add some HW troubles to this and I'll need to see where I am at this point. (I just damn well hope I have recent backups...) Well, I know my Win2K install is borked, along with my MDK 9.0 install (9.1RC1 seems fine but won't do for wine) been too scared to look for data that might have gone missing... Jaco-not-having-aloverly-time Hope your not-loverly-time improves! In the mean time I am pondering on the difference between a new small dog and a small new dog. Did you previously have a small dog (your old small dog) and a large one and replace the little one? OK, I'll stop talking nonsense now... :-) It's been a long day at work. David
Re: Was reading through the newest news and wondered about Transgaming'sfix.
I found a patch which I think was from them, and applied it to the cvs to try it out, it compiled OK but failed on startup and I haven't investigated it. David Mike Hearn wrote: I don't think anybody has a fix yet. The work TransGaming contributed was prototype code for using pthreads on non-x86 platforms iirc, it may well prove useful in the upcoming port to pthreads, but it's not a total solution On Mon, 2003-02-24 at 06:40, Joe Millenbach wrote: Did I read that correctly, in that they fixed whatever issues Wine has with glibc 2.3? So that issue with threads being different would be fixed with this? And if the above is true then are they planning to submit this to the Wine project or is this only for thier version? Thanks for your time, Joe Millenbach _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Re: x11drv, ntdll separation
David Hammerton wrote: On Tue, 25 Feb 2003 01:49, David Fraser wrote: Seems to make sense except that I still have one question: the MSDN docs seem to indicate that you need to call GDIFlush() before performing any drawing operations to the bitmap yourself (at least for Windows NT). Would it be possible to keep a list of DIBSections and flush them all in GDIFlush, or is this not adequate? I'm not familiar with GDIFlush(), but I just had a quick glance at the msdn docu for it, and it appears this is only relevent when using GDI in batch mode, (eg, do a bunch of GDI calls and then go 'render this') - and even then it still isn't required. Even if this function did what you wanted, it still wouldn't be possible to use properly because of speed issues (eg, we only coerce when we have to), and so on. (the same could be said for doing a coerce after each GDI call). David Right, but the MSDN documentation for CreateDIBSection says: *Windows NT/2000/XP:* You need to guarantee that the GDI subsystem has completed any drawing to a bitmap created by *CreateDIBSection* before you draw to the bitmap yourself. Access to the bitmap must be synchronized. Do this by calling the *GdiFlush* <http://msdn.microsoft.com/library/en-us/gdi/pantdraw_0enc.asp> function. This applies to any use of the pointer to the bitmap bit values, including passing the pointer in calls to functions such as *SetDIBits*. So internally, at least on Win NT/2000/XP, Microsoft themselves are doing this in a batched way and expecting to receive a GDIFlush before they have to update it. Speed-wise, I guess this may not be feasible because of the difference of using X, but actually, the user should call GDIFlush at exactly the points where we are picking up the page faults - when they're going to write to a bitmap that they've called GDI functions on. This might even therefore end up being quicker because there isn't the page fault handling overhead. Am I way off track? David PS The above doc is at http://msdn.microsoft.com/library/en-us/gdi/bitmaps_233i.asp further information from http://msdn.microsoft.com/library/en-us/tools/improve_77ar.asp below If you are writing an application that draws on the display, then the **CreateDIBSection** <http://msdn.microsoft.com/library/en-us/gdi/bitmaps_233i.asp> function can improve performance. This function allows you to share a memory section directly with the system, and thus avoid having it copied from your process to the system each time there is a change. Previously, a common practice was to call the *GetDIBits* <http://msdn.microsoft.com/library/en-us/gdi/bitmaps_7gms.asp> function, make the required changes, then call the *SetDIBits* <http://msdn.microsoft.com/library/en-us/gdi/bitmaps_0qk3.asp> function. These steps were often repeated on different scan lines of the bitmap before the image was ready for updating. Using **CreateDIBSection** is much simpler. One word of caution if you decide to use **CreateDIBSection**. You need to be sure that any calls that might affect your bitmap have completed before you start to draw in it. This is because the batching of GDI calls may cause their delayed execution. For example, suppose you make a *PatBlt* <http://msdn.microsoft.com/library/en-us/gdi/brushes_9vuc.asp> call to clear your bitmap, then you start to change the bits in your DIB section. If the *PatBlt* call was batched, it might not actually execute until after you start to make the bitmap changes. So, before you make changes to your DIB section, be sure to call **GdiFlush** <http://msdn.microsoft.com/library/en-us/gdi/pantdraw_0enc.asp> if you have made changes to the bitmap with earlier GDI calls.
Re: x11drv, ntdll separation
On Tue, 25 Feb 2003 01:49, David Fraser wrote: > > Seems to make sense except that I still have one question: the MSDN docs > seem to indicate that you need to call GDIFlush() before performing any > drawing operations to the bitmap yourself (at least for Windows NT). > Would it be possible to keep a list of DIBSections and flush them all in > GDIFlush, or is this not adequate? I'm not familiar with GDIFlush(), but I just had a quick glance at the msdn docu for it, and it appears this is only relevent when using GDI in batch mode, (eg, do a bunch of GDI calls and then go 'render this') - and even then it still isn't required. Even if this function did what you wanted, it still wouldn't be possible to use properly because of speed issues (eg, we only coerce when we have to), and so on. (the same could be said for doing a coerce after each GDI call). David -- David Hammerton Programmer TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: x11drv, ntdll separation
Mike Hearn wrote: What stage is the implementation currently at? According to the TransGaming docs, there are still a number of functions to fill in... I would be interested in seeing a patch no matter how much/little is implemented ... because my main aim in getting rid of the fault handler is so that the x11drv can be ported to Windows... Would that actually let you drop a file into MS Windows and suddenly allow any windows app to be export via X11 at the API level? If so, then all I can say is "whoa". If not, then, well, that'd be a cool hack some day :) Yup, that's the point ... will take quite a bit of work but until the x11drv and gdi32 dlls are separated out it's not even feasible ... if you're interested see http://sources.redhat.com/XOpenWin/ which is a currently quite dormant project to try do this. The relevant bugs for dll separation are: http://bugs.winehq.com/show_bug.cgi?id=538 DLL Separation: x11drv from gdi32 http://bugs.winehq.com/show_bug.cgi?id=540 DLL Separation: x11drv from user32 (clipboard) http://bugs.winehq.com/show_bug.cgi?id=542 DLL Separation: x11drv from user32 (misc) http://bugs.winehq.com/show_bug.cgi?id=543 DLL Separation: x11drv from ntdll (FILE_DupUnixHandle) http://bugs.winehq.com/show_bug.cgi?id=545 DLL Separation: x11drv from ntdll (VIRTUAL_SetFaultHandler) David
Re: x11drv, ntdll separation
Johan Gill wrote: Mike Hearn wrote: And I have it in my tree :) It should be ready for submission in a few months from now. Hvae you checked that it wouldn't be easier to merge in the TransGaming implementation? It seems daft to duplicate work if that's the case... It is their work, but I'm doing heavy changes. What stage is the implementation currently at? According to the TransGaming docs, there are still a number of functions to fill in... I would be interested in seeing a patch no matter how much/little is implemented ... because my main aim in getting rid of the fault handler is so that the x11drv can be ported to Windows... David
Re: x11drv, ntdll separation
David Hammerton wrote: Hi, I wrote some documentation a while back on this when we (TransGaming) submitted our dibengine to rewind/winehq. You can read the docu at: http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html Hi Thanks very much, this was very clear and I understand it now... Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, in that it has properties of both: The app can write directly to the pixel data while also being able to perform GDI operations on it, which we do through X. Because of the way X works we therefor have to have two copies of the DIBSection hanging around, and be able to sync them when required (eg, if the most 'up to date' version is in X, we need to know when the app tries to write to / read from the DIB so as we can sync them). Seems to make sense except that I still have one question: the MSDN docs seem to indicate that you need to call GDIFlush() before performing any drawing operations to the bitmap yourself (at least for Windows NT). Would it be possible to keep a list of DIBSections and flush them all in GDIFlush, or is this not adequate? And really - the best way to get rid of it is to finish the DIB engine :) OK, that makes sense now that I understand what it does :-) David David On Sat, 22 Feb 2003 22:36, David Fraser wrote: Hi I was wanting to do some work on x11drv dll separation. The last remaining dll separation between x11drv and ntdll is VIRTUAL_SetFaultHandler. This is called from X11DRV_DIB_CreateDIBSection, where it tries to set the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and arg=res. From reading the code it seems that this is done because it is not known whether the calling app requires read or write access to the data in bmp. If the app then tries to read or write and doesn't have the appropriate access, this will generate an exception which will then raise the X11DRV_DIB_FaultHandler which would then set the appropriate access, in a way that ensures data gets handled correctly. I presume I'm misunderstanding this, because looking at MSDN for CreateDIBSection, it says: The CreateDIBSection function creates a device-independent bitmap (DIB) that applications can write to directly. and further down... Windows NT: You need to guarantee that the GDI subsystem has completed any drawing to a bitmap created by CreateDIBSection before you draw to the bitmap yourself. Access to the bitmap must be synchronized. Do this by calling the GdiFlush function. So it would seem apps could always be given read-write access to this bitmap. Why is the special fault handler needed? What is the best way to approach getting rid of it? David
Re: annoyance running mingw
Dan Kegel wrote: Dimitrie O. Paun wrote: On February 24, 2003 12:46 am, Dan Kegel wrote: So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths. What about reversing the order: first try the DOS path, if that fails, try the Unix one... Hmm, that's a good idea. Same kinds of errors could happen, but they're probably a bit less likely... - Dan Seems to me the problem here is that mingw is passing these paths into Wine at all. The only apparent way to get to DOSFS_GetPathDrive is through DOSFS_GetFullName or DOSFS_GetShortPathName so either mingw is calling one of those functions with Unix path names or its calling some other Win32 API function with Unix path names which then calls one of those functions. But how would that work on Windows? Surely mingw should always convert unix paths to Windows paths *before* giving them to any Win32 function? David
Re: Fast thread-local storage for OpenGL drivers
> I suspect most of the old versions of Linux you're worried > about will vanish from user's desktops fairly quickly > as soon as Linux distributions ship versions that > include the current suite of improvements. (Not that > people will kill for the new glibc, but there are > a whole lot of improvements in font handling and > desktop apps coming out shortly.) Remember that wine runs on other OS (eg NetBSD) which isn't going to start using glibc ever David -- David Laight: [EMAIL PROTECTED]
Re: x11drv, ntdll separation
Hi, I wrote some documentation a while back on this when we (TransGaming) submitted our dibengine to rewind/winehq. You can read the docu at: http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, in that it has properties of both: The app can write directly to the pixel data while also being able to perform GDI operations on it, which we do through X. Because of the way X works we therefor have to have two copies of the DIBSection hanging around, and be able to sync them when required (eg, if the most 'up to date' version is in X, we need to know when the app tries to write to / read from the DIB so as we can sync them). And really - the best way to get rid of it is to finish the DIB engine :) David On Sat, 22 Feb 2003 22:36, David Fraser wrote: > Hi > > I was wanting to do some work on x11drv dll separation. > The last remaining dll separation between x11drv and ntdll is > VIRTUAL_SetFaultHandler. > This is called from X11DRV_DIB_CreateDIBSection, where it tries to set > the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and > arg=res. > > From reading the code it seems that this is done because it is not > known whether the calling app requires read or write access to the data > in bmp. If the app then tries to read or write and doesn't have the > appropriate access, this will generate an exception which will then > raise the X11DRV_DIB_FaultHandler which would then set the appropriate > access, in a way that ensures data gets handled correctly. > > I presume I'm misunderstanding this, because looking at MSDN for > CreateDIBSection, it says: > The CreateDIBSection function creates a device-independent bitmap (DIB) > that applications can write to directly. > and further down... > Windows NT: You need to guarantee that the GDI subsystem has completed > any drawing to a bitmap created by CreateDIBSection before you draw to > the bitmap yourself. Access to the bitmap must be synchronized. Do this > by calling the GdiFlush function. > > So it would seem apps could always be given read-write access to this > bitmap. > > Why is the special fault handler needed? What is the best way to > approach getting rid of it? > > David -- David Hammerton Programmer TransGaming Technologies Inc. [EMAIL PROTECTED]
x11drv, ntdll separation
Hi I was wanting to do some work on x11drv dll separation. The last remaining dll separation between x11drv and ntdll is VIRTUAL_SetFaultHandler. This is called from X11DRV_DIB_CreateDIBSection, where it tries to set the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and arg=res. From reading the code it seems that this is done because it is not known whether the calling app requires read or write access to the data in bmp. If the app then tries to read or write and doesn't have the appropriate access, this will generate an exception which will then raise the X11DRV_DIB_FaultHandler which would then set the appropriate access, in a way that ensures data gets handled correctly. I presume I'm misunderstanding this, because looking at MSDN for CreateDIBSection, it says: The CreateDIBSection function creates a device-independent bitmap (DIB) that applications can write to directly. and further down... Windows NT: You need to guarantee that the GDI subsystem has completed any drawing to a bitmap created by CreateDIBSection before you draw to the bitmap yourself. Access to the bitmap must be synchronized. Do this by calling the GdiFlush function. So it would seem apps could always be given read-write access to this bitmap. Why is the special fault handler needed? What is the best way to approach getting rid of it? David
Re: Problem with recent builds under RH8.0
Vincent Béron wrote: What's the output of rpm -q -f /usr/include/GL/gl.h and gl.ext? Mine's XFree86-devel-4.2.0-72, and I don't have any problem compiling Wine with OpenGL. My GL headers are from the CVS pull of DRI, so they aren't owned by any package.
Re: Problem with recent builds under RH8.0
Sylvain Petreolle wrote: whats your videocard and your drivers model/version ? xdpyinfo and glxinfo attached. Basicly a pull of the DRI CVS. name of display::0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x10feb80, revert to Parent number of extensions:28 BIG-REQUESTS DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1600x1200 pixels (363x275 millimeters) resolution:112x111 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x3e depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa003f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMaskEnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:8 default visual id: 0x23 visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x24 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x25 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x26 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x27 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x28 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x29 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x2a class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits display: :0.0 screen:0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Radeon 20010402 AGP 2x x86/MMX/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_comp
Re: Problem with recent builds under RH8.0
Uwe Bonnes wrote: Often for such problems a "make distclean", .configure , make depend and make sequence helps. Bye Not this time. Same result.
Problem with recent builds under RH8.0
Ever since upgrading to RH8.0, I've been getting the following errors when building Wine - even with a fresh CVS pull: device.o: In function `DrawPrimitiveI': /usr/src/wine/dlls/d3d8/device.c:392: undefined reference to `glMultiTexCoord2f'/usr/src/wine/dlls/d3d8/device.c:416: undefined reference to `glMultiTexCoord3f'/usr/src/wine/dlls/d3d8/device.c:516: undefined reference to `glMultiTexCoord2f'/usr/src/wine/dlls/d3d8/device.c:535: undefined reference to `glMultiTexCoord3f'/usr/src/wine/dlls/d3d8/device.c:730: undefined reference to `glClientActiveTexture' /usr/src/wine/dlls/d3d8/device.c:764: undefined reference to `glMultiTexCoord4f'device.o: In function `setupTextureStates': /usr/src/wine/dlls/d3d8/device.c:981: undefined reference to `glActiveTexture' device.o: In function `IDirect3DDevice8Impl_SetRenderState': /usr/src/wine/dlls/d3d8/device.c:2548: undefined reference to `glActiveTexture' device.o: In function `IDirect3DDevice8Impl_SetTexture': /usr/src/wine/dlls/d3d8/device.c:2977: undefined reference to `glActiveTexture' device.o: In function `IDirect3DDevice8Impl_SetTextureStageState': /usr/src/wine/dlls/d3d8/device.c:3156: undefined reference to `glActiveTexture' collect2: ld returned 1 exit status make[2]: *** [d3d8.dll.so] Error 1 make[2]: Leaving directory `/usr/src/wine/dlls/d3d8' If I disable the build of the D3D system, Wine builds and runs.
Re: Looking for information on implemented API's in wine
Dave Miller wrote: I've never actually had any intention of everyone needing to install MySQL in order to make use of the database. I had planned on it being a single database, accessible via the web. Querying would be done via forms. It seemed the easiest way to present all the data in a single place. I also thought it might be possible to enter application data, so that it can be queried for APIs the app requires, etc. Right now I will certainly work toward a flat file. I had intended to start with that anyway, and it is easily imported into SQL if choose to move in that direction. But as I've said, I'm certainly not an experienced programmer and so I have no real idea of what is possible with perl plus the power of awk. But I am sure once we can gather the data someone will be happy to help find ways to query it. :) Another advantage of it being in a flat file is that different people can work on different versions of it and use diff, patch, cvs, etc to maintain them. This wouldn't be possible just through having a simple web interface. David
Looking for information on implemented API's in wine
I am ready to begin work on the actual database aspect of cross referencing the windows dlls. As part of the database I would like to include the status of a given API in wine so it will be possible to do things like query for all unimplemented APIs in a given dll. The first questions I have are whether or not I can depend on the spec files to give a complete list, and can someone either point me to documentation on the spec files or explain everything I need to know in order to determine the status of APIs defined there?
Re: CreateNamedPipe error values?
Dan Kegel wrote: I wrote a humble beginning of a conformance test for named pipes, in hopes of preventing regressions like the one which is currently breaking Installshield installs (or was last I checked). Later it's going to verify that named pipes like the ones Wine uses internally (e.g. in ole32/rpc.c) actually work, For now I thought I'd just make sure we return the right error code if you pass a bogus filename to CreateNamedPipe. But, um, we don't return any error code; we happily succeed. Can somebody who has Windows Server run this little test, and tell me what it outputs? You can build it as part of the wine test suite, or standalone with the commands call \vcvars32.bat cl /D STANDALONE /D _X86_ /D _M_IX86 /D WIN32 /D _WINDOWS pipe.c Thanks, Dan Built it standalone, need to add #include above the windef.h header Output was a single line: h , err 123 This is on Windows 2000 Professional, but I'm pretty sure (as said before) you don't need Server for named pipes... David
Re: NamedPipe conformance tests
Dan Kegel wrote: A couple questions: 1. Is anyone working on NamedPipe conformance tests? If not, I'd be happy to try. (Might be a challenge to scare up a Server version of Windows, so initially I'd just write the tests on Wine, and make sure they compiled with winelib and with vc++.) 2. Since CreateNamedPipe is only available on Server versions of Windows, we need a way to avoid running the test on non-server versions. Er, I suppose checking for the presence of CreateNamedPipe would be the way to go :-) I at first tried detecting the Windows version, but that's far too hairy. - Dan Are you sure CreateNamedPipe is only available on Server versions of Windows? Seems to be there in Windows 2000 Professional... David
Windows API script updated
I've updated my script to output imported_api.html which lists all of the dlls and the specific APIs imported from other dlls. Hopefully that is a bit more useful than just which dlls are imported. There is a sample output here: http://home.ptd.net/~compsol/imported_api.gz It is about 800kb gzipped. It was 7MB before compressing. :) If anyone is interested, the script is attached again. You'll need to run with -parse to get this HTML. Now, should exported APIs somehow be part of the HTML as well?
Re: Converting wine to pthreads
Dan Kegel wrote: David Fraser wrote: Dan Kegel wrote: However, it's not clear to me that's required for developing winethreads-over-pthreads. People could probably get started on that with their current Linux, even though it's not 100% posix-compliant, and has odd quirks like using a special management thread, etc. Exactly. Who's going to start it? According to a recent post, a quick try at basing things on pthreads is at http://www.geocrawler.com/archives/3/9376/2001/12/50/7309863/ but I guess there's more to be done. So the question is, who's going to be the first to get a "new pthreads" Linux system up and running to verify the problem and try out that patch? (http://kt.zork.net/wine/wn20030131_155.html#2 has a nice summary of recent discussions, but searching google for wine pthreads yields a few interesting tidbits, too.) - Dan Seeing as nobody talked about this for a while, I decided to take this patch and integrate it into my CVS copy... I did and the relevant files compile fine, with one warning gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -Wpointer-arith -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o ../../scheduler/sysdeps.o ../../scheduler/sysdeps.c ../../scheduler/sysdeps.c: In function `SYSDEPS_SpawnThread': ../../scheduler/sysdeps.c:219: warning: passing arg 3 of `pthread_create' from incompatible pointer type Not being an autoconf wizard I had to define USE_PTHREADS manually in the files ... how could I add a --enable-pthreads switch? When compiled, gave me the following error linking wine in miscemu: gcc -o wine wine.spec.o main.o -L../dlls -lntdll.dll -L../library -lwine -L../unicode -lwine_unicode -lm ../dlls/libntdll.dll.so: undefined reference to `pthread_create' ../dlls/libntdll.dll.so: undefined reference to `pthread_attr_setstackaddr' ../dlls/libntdll.dll.so: undefined reference to `pthread_once' ../dlls/libntdll.dll.so: undefined reference to `pthread_attr_setstacksize' ../dlls/libntdll.dll.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status make[1]: *** [wine] Error 1 If I tried to add libpthread, I got: gcc -o wine wine.spec.o main.o -L../dlls -lntdll.dll -L../library -lwine -L../unicode -lwine_unicode -lm -lpthread ../dlls/libntdll.dll.so: the use of `pthread_attr_setstackaddr' is deprecated, use `pthread_attr_setstack' so I replaced that, and it got rid of the warning... Then everything links fine, but running gives an error because of an assert in library/port.c because the pthread functions in scheduler/pthreads.c had been compiled out in the patch. I compiled them back in and wine just hangs... Hmmmm .... not very useful to anyone but I'd thought I'd let you know. If anyone wants I can post the patch (to wine-patches?) David
Re: Windows API (What I have so far)
I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs. The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser? At 09:39 AM 2/9/2003 +0200, you wrote: Dave wrote: Thanks, I will look into merging the two together sometime soon, if no one beats me to it. First I want to make the existing program a little more readable before it becomes unmanageable and even I don't know what it does. :) The sample HTML I created was done from my laptop, which has all sorts of applications installed. There might be a lot of irrelevant information. It may become a much smaller table once it's run on a clean system. Please keep the foreend/backend approach, as I have neither tools nor environment to run your original perl prog, and I would still like to get the HTML rendering. I think the best approach is for a backend to dump the raw data into a easy to parse format (and your original format was, as you can see, not too difficult once you add the newlines), and a frontend that formats these into HTML. As for the unnecessaries - 238 columns is much better than I feered. More worriying than the sheer number is the warning my prog issues when run on your original input (like I said - I don't have any other): DLL fsusd depends on DLL gdiplus, which does not exist DLL photowiz depends on DLL gdiplus, which does not exist DLL shmedia depends on DLL gdiplus, which does not exist DLL webvw depends on DLL gdiplus, which does not exist DLL wiadefui depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavusd depends on DLL gdiplus, which does not exist Manually checking that with your output reveals that to be a correct assesment (i.e. - not a bug). there are references to a DLL called "gdiplus", which does not itself show in the output. Care to check your system and find out how that came about? Shachar At 01:11 AM 2/9/2003 +0200, you wrote: Attached is a perl prog that taked David's original HTML output with a single necessary preprocessing (replacing each with \n), and issues a list of the DLLs (no deps as of yet) in the order discussed before (i.e. - A depends on B -> A is higher, A has more dependants than B -> A is higher). I will now work on displaying this in a table. Shouldn't be too difficult (the fact that the table will be 238 coloumns wide nonwithstanding). Could be worse. The table is 1141 lines long. This does not work with David's new prog yet, but as the both of them are in perl I am sure it will not be too big a deal to merge the two progs into one. This will just simplify the process of getting the initial input (currently parsed from the HTML). Shachar Shachar Shemesh wrote: Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like. Shachar Quoting David Miller <[EMAIL PROTECTED]>: I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors. It is far from complete, but at this stage does the following: - Scan a given path, locating all dll files - Generate an HTML map of dll imports only (sorted, lowercase, stripped of paths) - dumpbin /import and dumpbin /export on all dll files and save the results in imports.txt and exports.txt respectively - parse imports.txt as follows, and save the results in imported_api.txt: DLL nameimported DLLimported API - parse exports.txt as follows, and save the results in exported_api.txt: DLL nameexported API Future plans: - Create a matrix of data currently in HTML map - Generate HTML cross reference of all imported/exported API - Implement dumping of data into a database (Something queryable, but what?) - Detect and report unimplemented APIs in wine -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/ -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Tried to install Red Alert - Yuri's Revenge
and it failed. The installer said that comctl32.dll was too old, did I want a new one, so I said no. They it said that DirectX was a level 0 (well actually a long list of 00.00s), and asked if I wanted to install what looked like version 4 (although the docs with the CD say that it will install 8.0a). When I said no to that the installer quit. This was a Debian unstable system, which is using the latest Wine.deb. So how is it detecting the age of comctl32, and how should I convince it that the dll really is up to date, and do I need to install the front bits of DirectX in order to use the support that Wine is now increasingly providing, or should Wine be advertising its DirectX support differently. This is the first time I have tried to install a DirectX program on the machine, and I do not know quite how I should proceed. Thanks in advance David
Re: AppDB updated
I think that just means no one actually has rated that particular app yet. When you submit an app it does not require you to rate how well it works. At 05:01 AM 2/9/2003 +0100, you wrote: there is some problem I think. I looked at utilities/filesystem. almost every app is set to level 0. example : ddrcrypt.exe, reported as "Works really well!!" in desc, is set to level 0 ! http://appdb.winehq.org/appview.php?appId=876 --- Andreas Mohr <[EMAIL PROTECTED]> a écrit : > Hi all, > > I just (well, not "just": more like a matter of a whole week or so) > committed about 170 or so new entries to the AppDB, thus reaching > a count of 1523 distinct applications. > > I guess I'm feeling really exhausted now... > > Anyway, have fun browsing the site at http://appdb.winehq.org ! > > Andreas Mohr > = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Windows API (What I have so far)
I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors. It is far from complete, but at this stage does the following: - Scan a given path, locating all dll files - Generate an HTML map of dll imports only (sorted, lowercase, stripped of paths) - dumpbin /import and dumpbin /export on all dll files and save the results in imports.txt and exports.txt respectively - parse imports.txt as follows, and save the results in imported_api.txt: DLL nameimported DLLimported API - parse exports.txt as follows, and save the results in exported_api.txt: DLL nameexported API Future plans: - Create a matrix of data currently in HTML map - Generate HTML cross reference of all imported/exported API - Implement dumping of data into a database (Something queryable, but what?) - Detect and report unimplemented APIs in wine winapi_listing.pl Description: Binary data
Re: Converting wine to pthreads
Dan Kegel wrote: However, it's not clear to me that's required for developing winethreads-over-pthreads. People could probably get started on that with their current Linux, even though it's not 100% posix-compliant, and has odd quirks like using a special management thread, etc. Exactly. Who's going to start it? Actually this message is just to say that I think we should change the subject of this thread... David
Re: Started playing with Wineserver on mingw/cygwin again
Dimitrie O. Paun wrote: On February 5, 2003 03:36 am, David Fraser wrote: Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork. Do threads in Cygwin's pthreads map one-to-one to Windows threads? Just looked at the Cygwin source, and it looks like they do. pthread::create in src/winsup/cygwin/thread.cc calls native Windows ::CreateThread and stores the returned HANDLE in win32_obj_id (a member of the pthread class). This is then accessible as (*thread)->win32_obj_id from the pthread_t *thread pointer. So that looks sufficient ... if Wine can use ptherads... David
Re: Started playing with Wineserver on mingw/cygwin again
David Fraser wrote: Dimitrie O. Paun wrote: On February 1, 2003 02:10 am, David Fraser wrote: Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating? I don't know the Cygwin threading model, but calling the real [GS]etThreadContext is a good first order approximation. If interested in this task, I'd bring it up on the Cygwin mailing list... Just as a start, I tried this ... compiles fine but don't know how to test it ... Does this look right? (just done for get_thread_context) David OK, having actually thought I can see that this is not going to work. Basically in order to do a GetThreadContext we need to get a handle to the underlying Windows thread... what I was doing here was asking the Wine server for a handle to the thread, then passing that to Windows. I've now tried to look at the code to see what exactly the correspondence between threads on Wine running on cygwin to underlying native threads would be. (I then discovered I'd already done this previously: http://www.winehq.com/hypermail/wine-devel/2002/11/1533.html) I'm fairly ignorant about the code so I'd appreciate any feedback on my comments here. From examining the code it looks to me like in Wine, "Windows" threads are created in scheduler/sysdeps.c:SYSDEPS_SpawnThread, where there is a call to clone which creates the thread. "Windows" threads are initialized by sending request in the client code: In scheduler/client.c, CLIENT_InitThread uses getpid() to determine the unix_pid in req which then gets set on the thread in server/thread.c:init_thread. Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork. Can Wine use pthreads to implement its threading? David
Re: Started playing with Wineserver on mingw/cygwin again
Dimitrie O. Paun wrote:
On February 1, 2003 02:10 am, David Fraser wrote:
Could we go straight down to the underlying win32 api and do a
GetThreadContext there? Is that cheating?
I don't know the Cygwin threading model, but calling the real
[GS]etThreadContext is a good first order approximation. If
interested in this task, I'd bring it up on the Cygwin mailing
list...
Just as a start, I tried this ... compiles fine but don't know how to
test it ...
Does this look right? (just done for get_thread_context)
David
Index: server/context_i386.c
===
RCS file: /home/wine/wine/server/context_i386.c,v
retrieving revision 1.24
diff -u -r1.24 context_i386.c
--- server/context_i386.c 8 Nov 2002 18:55:31 - 1.24
+++ server/context_i386.c 4 Feb 2003 17:53:57 -
@@ -76,7 +76,31 @@
#define PTRACE_SETDBREGS PT_SETDBREGS
#endif
-#ifdef linux
+#if defined(__CYGWIN__)
+
+/* need to access handles... */
+#include "handle.h"
+
+/* retrieve a thread context */
+static void get_thread_context( struct thread *thread, unsigned int flags, CONTEXT
+*context )
+{
+/* get a handle to the thread with all access, not inheritable */
+HANDLE hThread = alloc_handle(thread->process, thread, THREAD_ALL_ACCESS, 0);
+/* cheat and call underlying Windows GetThreadContext directly... */
+BOOL success = GetThreadContext(hThread, context);
+/* now release the handle... */
+close_handle(thread->process, hThread, NULL);
+}
+
+
+/* set a thread context */
+static void set_thread_context( struct thread *thread, unsigned int flags, const
+CONTEXT *context )
+{
+/* FIXME: implement this */
+file_set_error();
+}
+
+#elif defined(linux)
#ifdef HAVE_SYS_USER_H
# include
#endif
Using the real Windows kernel
I'm not a programmer and I know this is not your goal... but: Woulden't it help if Windows users just copied the kernel from their Windows installation and used this for an alternative desktop/system? - I mean the Windows NT kernel seems to work alright, but all the things Microsoft put on top of it slows it down and locks people away from settings and confuses them etc... if you had people use the real kernel instead (without offering it online of course) Windows users could use YOUR desktop/GUI implementation but still use all the existing drivers and apps... and have faster and more configurable computer using your alternative desktop. I know a lot of Windows users who would want such an alternative... just a thought... --David Filskov Denmark
Re: PATCH: Get rid of superfluous dup() and close() calls.
> What happens under Windows with such circumstances?
Who knows, I've never used windows (well almost never),
people don't seem to mind windows locking solid :-)
David
--
David Laight: [EMAIL PROTECTED]
Re: PATCH: Get rid of superfluous dup() and close() calls.
> I'm not sure I agree. When someone closes a fd they shouldn't, that > would lead to program crashing, and attention being brought to the > problem. When someone leaks a fd, noone will notice. No, it causes horrid corruptions that are particularly difficult to find. What happens is that someone else does an open() and is given the number of the (incorrectly) closed fd. The owener of the fd will then write into the newly opened file. This can happen if a 'normal' program does close(0), close(1), close(2) then much later accidentally calls printf() instead of sprintf(). When the stdio buffer is eventually flushed data is written to what has been reopened as fd0. (This was a real bug in software that got released...) David -- David Laight: [EMAIL PROTECTED]
Re: Started playing with Wineserver on mingw/cygwin again
Steven Edwards wrote: well I made it serial.c before I had to run to work. I'm having good luck getting alot of the objects to compile so far I've only had to kill file.c, ptrace.c, request.c and select.c. Getting this to build and run on Windows is going to be a bitch =) gettimeofday, fork and all of fd and networking is going to be the hard part. I've started a tempory header to see what will need to be implemented in libwine if we want to get wineserver up and running on Windows without cygwin. Cygwin still really needed get/setthreadcontext (hint, hint) OK, as far as I understand it this means we need to implement a cygwin version of get_thread_context and set_thread_context in server/context_i386.c. What I'm not sure about is, when running wineserver on cygwin, would the threads created in Wine have a one-to-one correspondence to Windows threads? Or would they be strange, different, unix-style threads which cygwin then maps down to Windows threads? Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating? David
Re: RPC marshalling patch
> > > and here is some free-as-in-beer RPC 1.1 stuff: > > > > http://www.opengroup.org/products/publications/catalog/c706.htm > > And on there, they just want to borg the email addresses of every reader, > but not their souls or firstborns, as far as I can see. When they set up this 'free' access to the documents it was rather a change of direction for (what was then) X/Open. After all they had a business model that assumed they would be making money from selling the books, rather than just taking money from the contributing companies and giving away a 'free' copy of each book to each company. In any case they wanted a log of who was downloading stuff, but they said at the time that the email addresses wouldn't be used for other purposes. I've certainly never received junk mail from them. I suspect the log (like the ones from anon ftp passwords) is of little use to anyone. David -- David Laight: [EMAIL PROTECTED]
Re: common file dialogs
> At the > very least I think it should be a pref, wading through lots of dotfiles > in your home dir makes it much harder to open files with wine, and > obviously non-technical users will wonder what is going on with all > these stranges folders that I never made.. maybe it'll make them clean up the mess in ~ mine gets full of .prxh0622a, .twmc0524a and .xsma0478b files (probably because I shutdown from within X) David -- David Laight: [EMAIL PROTECTED]
Windows API database
I would be interested in knowing more about the goals of this project. Don't consider me officially working on such a thing just yet. I have no real perl experience, but would like to learn. First I'd like to know more about what I'm up against. 1. Is there a specific set of dll's and exe's we want included in the database or does it need to scan and gather a list of all dll and exe files? That would suggest a clean OS install is necessary. 2. What information should be in the database? (OS ver, name of dll or exe, name of imported dll, APIs and whether they are imported or exported, etc.) 3. Will a single MySQL table do or does it need to be a relational database with multiple tables? 4. Anything else you can tell me about this task?
LockFile support
I have an old, nasty application that uses the Paradox database engine. This app attempts to lock the database files using LockFile. Now, it USED to work under Wine. It no longer does. The program coughs up an error "No access to directory", and stderr shows a bunch of "LockFile not supported in server" errors. Did the behavior of LockFile change in the past couple of months? Are there plans to add LockFile support into Wine?
Re: getting started
Francois Gouget wrote: 2. we can modify Winemaker to generate Mingw makefiles (does that rule out using autoconf?) and assume that a 3 line change will turn them into Winelib makefiles (or the other way around). Actually, has anyone written a .dsp to Mingw makefile converter? http://lnxscene.org/jylam/dsp2make/ Details: GPL, written in C, at version 0.3 (May 2002) Seems very simple and would need quit some work but I ran it on some of my projects and seemed to produce something reasonably sensible. Maybe we could take this and develop it. Alternative would be to do it in Perl etc. I don't know Perl. bother.
Re: getting started
Francois Gouget wrote: On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: On January 7, 2003 02:25 pm, Francois Gouget wrote: * winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary. This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive: [...] -- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right? I think our views are not incompatible and even that we basically agree. However there is a difference in emphasis. I'm more interested in improving the front-end, especially by adding support for dsp file which I think would improve the usefulness of winemaker tremendously (so that's what I would work on if I had time). You are more interested in the backend and in making it compatible with MinGW. However since I probably won't have time to make significant changes to winemaker in the near future my preferences are moot. Call for help: Please if you are interested in working on either aspect let us know (me or Dimitrie) and we will try to help you each with the part we are more familiar with. Me! Do we have a task list for this? David
Re: Removing (HANDLE)NULL casts (2)
> Zero is fundamentally built into the language so deep, that playing > with tricks like NULL and '\0' seem like a waste of time. FWIW I agree. In C the character '0' appearing in a source file is the correct denotation for a 'null' pointer even when the bit-pattern for a null pointer isn't all zeros. ie the value assigned by 'ptr = 0;' could be different from that generated by 'int i = 0; ptr = (void *)i;' Similarly 'if (ptr) ...' and 'if (!ptr) ...' are valid checks for a null pointer, save 8 bytes on the line and stop the (usually) erronous 'if (ptr = NULL) ...'. David -- David Laight: [EMAIL PROTECTED]
Re: Handle table? win2k internals doc?
On Sat, Jan 04, 2003 at 11:23:21PM -0800, Dan Kegel wrote: > On the off chance that MSVC6's installer is cheating > and reading the handle table entries directly by > dereferencing file handles, I started wondering whether > wine needed to make all its handles look a bit more like > windows handles. > > What's the best source of info about how Windows formats > its handles and arranges its handle table? > > "Inside Microsoft Windows 2000" > by David A. Solomon and Mark Russinovich > http://www.sysinternals.com/insidew2k.shtml > seems like a good source of info. Is it worth the $35 > for a budding wine hacker? > W2K/NT/XP and 9X are very different in how handle tables are structured - for W2K: "Inside Microsoft Windows 2000" has 3 pages on the subject, "Undocumented Windows 2000 Secrets" by S. Schreiber is more detailed including some information like the object headers which aren't covered anywhere else. It's worth noting that the handles for executive objects (files, threads, events, etc) are in kernel-mode and shouldn't be accessible to user-mode programs except through the native API or injecting a driver. There are also user-mode handle systems for GDI/USER objects, consoles and the various stdio implementations - I don't know of any published internals information on these.
Windows XP conformance test update 1/5
Not much to report this time but there is something... strange. kernel32/drive reported the following. C:\winetests>kernel32_test.exe drive drive.c:113: Test failed: GetDiskFreeSpaceA(Z:\): ret=0 GetLastError=53 drive.c:165: Test failed: GetDiskFreeSpaceW(Z): ret=0 GetLastError=53 drive: 156 tests executed, 0 marked as todo, 2 failures. Previously this test passed, so I rebooted to see if the problem went away. After reboot the kernel32 test clamed not to be a valid win32 application. Turns out the size was 0 bytes. I re-extracted the zip file and ran kernel32/drive again. This time is passed. I have not seen the failure before but I did run into the "not a valid win32 application" message before, and the file size was 0 bytes. Normally I would suspect a virus to produce that sort of problem, but I've only seen this happen to the kernel32_test.exe file. I will attempt to find out if it can be reproduced and how. I have an XP laptop as well so I'll try to verify it is not a system specific problem. oleaut32/safearray reports 8 failures but the page only shows 4 failures. C:\winetests>oleaut32_test.exe safearray safearray.c:137: Test failed: SAC(20,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(20,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:137: Test failed: SAC(21,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(21,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray: 958 tests executed, 0 marked as todo, 8 failures. Also I don't see urlmon/generated on the status page at all. It passed. C:\winetests>urlmon_test.exe generated generated: 4 tests executed, 0 marked as todo, 0 failures.
Re: Update: Wine & Mozilla
Steven Edwards wrote: I will be lending those guys a hand with the port. Mostly the work seems to be done, they just need a gentle nudge to get it in the tree (I hope :)). As always, your comments and suggestions are highly appreciated. when/if I ever get more time I will try to help. I just got married so my time to work on wine/reactos/mingw has gone to /dev/null for about another month. btw: nice work on visual-mingw. Thanks Steven __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Congratulations! Definitely worth the break...
Re: Update: Wine & Mozilla
Dimitrie O. Paun wrote:
Hi folks,
For those of you who follow my Winelib quest, one of the most
ambitious projects is compiling Mozilla under Wine. Needless
to say, this would be quite something to accomplish, and would
provide Wine with a formidable test for it's headers, and it's
tools (wine{build,gcc,wrap), wrc).
The goal of course is to port the entire beast with very little
changes. For anyone who looked at the source, it should be clear
that this is the only way it can happen. If it requires massive
work, I'm just not going to do it.
To accomplish this task, Mozilla needs to build first on mingw.
Unfortunately, Mozilla still requires MSVC to compile on Windows.
There is an ongoing effort that is tracked in bug #134113:
http://bugzilla.mozilla.org/show_bug.cgi?id=134113
I will be lending those guys a hand with the port. Mostly the
work seems to be done, they just need a gentle nudge to get it
in the tree (I hope :)).
As always, your comments and suggestions are highly appreciated.
Hi
I've read the bug, downloaded the source, trying to compile it on my
Windows box...
Applied the patches (straight-code.patch and rest.patch).
But I'm not sure what the standard way of trying this out is
Particularly should I be using the mozilla tools in the path, should I put
them before or after msys/mingw/cygwin, will they cause problems?
(Basically if they're first in the path then it says the host type is
i586-pc-msvc, but if not, then it picks up i686-mingw or cygwin etc).
David
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun wrote: On January 2, 2003 12:30 pm, Alexandre Julliard wrote: It doesn't really matter, just pick the one you prefer. I know, but I was hoping people had better suggestions :) I like __WINESRC__ the best (but that doesn't mean much ), so unless people have a better idea, that's going to be it. Not that this really matters, but what about __BUILDWINE__? Then #ifdef __BUILDWINE__ would seem to me to more clearly say "if we're building wine" Anyway I don't really mind but thought you deserved at least one suggestion in response to your plea... David
WinXP conformance test update
I noticed two tests were still missing information. Here are the results of those tests. C:\winetests>kernel32_test.exe file file.c:633:Current offset = 0015 file.c:658:Current offset = 0015 file: 487239 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe generated generated: 609 tests executed, 0 marked as todo, 0 failures.
Re: [JOY] wxWindows
Dimitrie O. Paun wrote:
Folks,
Last night I managed to compile, link, and successfully run
all(1) samples that come with wxWindows.
In all honesty I am overjoyed! Let me explain why:
Excellent news!
-- wxWindows is a large piece of software that touches on
most (if not all) Wine aspects. It does put our headers
through their paces.
-- The porting effort has been simple, and it took me
a just a few days to do it.
-- I have not used _any_ of the previous efforts to port
wxWindows to Wine. I rather started with their MinGW port.
-- Most of the changes have been trivial fixes for Wine
which I have sent to wine-patches in the last few days.
-- The hacks to wxWindows have been trivial and few in
number. I have touched only a few files, and the
changes are real simple. They'll need some cleaning up,
and I'll submit them to the wxWindows folks for inclusion.
-- The wine{gcc,wrap} combo is a great success. All I had
to do was to touch only *one* file (makeg95.env), and
modify only a few lines to get *everything* to compile
and link.
What does Wine get out of it:
-- A good test for our headers
-- Proof that wine{gcc,wrap} are a good idea (at least for me)
-- A large number of sample that show quite a few problems in Wine.
If anyone is interested in more details please let me know, and I'll
be glad to provide them. Once we decide on the __WINE__ vs. __WINESRC__
thing, I'll cleanup the wxWindows changes and submit them for inclusion
in their tree, so hopefully you'll be able to play with it using the
official version not before long.
I'd be very interested in this, as I use wxWindows alot in my work...
This means we can try compile our app like this (it already kind of works
using wxGTK, but this will be interesting too)
Thanks a lot...
David
Re: strcasecmp
Dimitrie O. Paun wrote: On December 19, 2002 09:26 am, Waldek Hebisch wrote: If we are going to seriously support mingw then we need "mingw headers". I am not sure if true mingw headres are different enuugh from normal wine and msvcrt headers to warrant extra subdirectory, but logically they form a separate set. I suggest to put conditionls (if needed) in msvcrt headers corresponding to mingw headers, and make a separate subdirectory for mingw headers which emulate Unix headers. Right. I haven't looked at the mingw headers, but I assume they are rather similar to the ones in glibc. If that's the case, we can reuse those (if you have gcc which you have to anyway if you want to use the mingwrap stuff): [dimi@dimi wine.src]$ sed -n 290,296p /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h #ifndef __WCHAR_TYPE__ #define __WCHAR_TYPE__ int #endif #ifndef __cplusplus typedef __WCHAR_TYPE__ wchar_t; #endif #endif Which means we can simply -D__WCHAR_TYPE__=unsigned\ short But we still can not link. For that, we need to reimplement all wchar_t using functions, and link those in before the glibc ones. Linking tricks are not my strenght, anyone know how we can do that? Does it work to just place a lib with those symbols first in the -l list? Not sure exactly what you're looking for here - but I think you're wanting to know about the way it resolves symbols. Basically symbol lookups are only done in libraries that appear later on the command line than the one needing the symbol. So if libb.a depends on liba.a, then gcc bladibla -lb -la will work while gcc bladibla -la -lb will fail. Hope that's relevant David
Re: [D3D8 PATCH] d3d8 shaders update - VS2
On Thu, Dec 19, 2002 at 07:08:40AM -0500, Dimitrie O. Paun wrote:
> On December 19, 2002 05:29 am, David Laight wrote:
> > No, and I would use it if I did :-)
^^^
not
Finger trouble...
> http://www.vim.org
Probably...
David
--
David Laight: [EMAIL PROTECTED]
Re: [D3D8 PATCH] d3d8 shaders update - VS2
> >Actually it could be considered as an editor fault if it changes color for > >commented out code but doesn't recognize the #if 0/#endif construct. I'd tend to agree... OTOH I don't like colour :-) > I wouldn't say so. A comment is easily recognized by the chars /* */ or //. No it isn't! You still have to know the language in order to get quoting right. Try editing an m4 source file! > But to get a #if 0 or #if _ANYTHING you really need a language dependant > preprocessor which goes beyond a normal text editor, even one with > syntax coloring. The only difficulty is knowing which half of the #if ... #else ... #endif to parse. Parsing both is wrong and will lead to miscoloration. > Do you have such a text editor that finds #if's? No, and I would use it if I did :-) David -- David Laight: [EMAIL PROTECTED]
Re: mingwrap -> mingcc
Francois Gouget wrote: On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: On December 18, 2002 03:36 pm, Francois Gouget wrote: [...] winegcc Why not wgcc? I had the impression that we were going away from just using 'w' as the prefix and more towards using 'wine'. So I'm proposing both forms. So I am OK with the following: wgcc mingcc wmingcc I think the ones I prefer are 'wgcc' and 'winegcc'. In both cases we can add variants: wcl / winecl (Visual C++), wbcc / winebcc (Borland C++ if memory serves), etc. I'm all for winegcc and these variants. It's not that much longer to type, it's much clearer (nobody's going to look at their /usr/bin directory and think 'what's wgcc?'), and most of the time it's going to be in a Makefile anyway. David
WinXP Professional conformance test update
Here are the results of all the tests which produced different results today using the new binaries, as well as output from tests I didn't run previously because I didn't realize they existed. (I followed the script) C:\winetests>dsound_test.exe dsound dsound.c:56:Testing Primary Sound Driver - dsound.c:70: DirectSound Caps: flags=0x0f5f secondary min=5000 max=44100 dsound.c:100: PrimaryBuffer Caps: flags=0x0009 size=32768 dsound.c:113: tag=0x0001 22050x8x2 avg.B/s=44100 align=2 dsound.c:129: status=0x dsound.c:56:Testing Sound Blaster AWE64 - ctlsb16.sys dsound.c:70: DirectSound Caps: flags=0x0f5f secondary min=5000 max=44100 dsound.c:100: PrimaryBuffer Caps: flags=0x0009 size=32768 dsound.c:113: tag=0x0001 22050x8x2 avg.B/s=44100 align=2 dsound.c:129: status=0x dsound: 27 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe file file.c:633:Current offset = 0015 file.c:658:Current offset = 0015 file: 487239 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe path path.c:514: Test failed: GetLongPathNameA: wrong return code, 106 instead of 46 path.c:889:TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp path.c:900:TMP=C:\WINDOWS path.c:910:TMP=C:\ path.c:920:TMP=C: path: 1800 tests executed, 0 marked as todo, 1 failure. C:\winetests>msvcrt_test.exe scanf scanf: 6 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe generated generated: 609 tests executed, 0 marked as todo, 0 failures. C:\winetests>shlwapi_test.exe generated generated: 19 tests executed, 0 marked as todo, 0 failures. C:\winetests>shell32_test.exe generated generated: 272 tests executed, 0 marked as todo, 0 failures. C:\winetests>user32_test.exe generated generated: 1524 tests executed, 0 marked as todo, 0 failures. C:\winetests>wininet_test.exe generated generated: 252 tests executed, 0 marked as todo, 0 failures.
Re: WinXP Test Oddities (Changed Test Results!!)
Sorry if this appears on the list twice. I sent from the wrong address the first time and messages seem to not appear on wine-devel unless I send from the address I have subscribed. Ok, I've rebooted and done advapi32_test.exe registry again. It now seems to hand halfway through the test. Here is the output on WinXP Pro: C:\winetests>advapi32_test.exe registry registry.c:80: Test failed: data_count set to 24 instead of 7 registry.c:81: Test failed: type 2 is not REG_SZ registry.c:94: Test failed: data_count set to 24 instead of 7 registry.c:95: Test failed: type 2 is not REG_SZ registry.c:96: Test failed: value set to 'xx' instead of 'Te' registry.c:97: Test failed: data set to 'xx' instead of 'foobar' registry.c:108: Test failed: data_count set to 24 instead of 7 registry.c:109: Test failed: type 2 is not REG_SZ registry.c:111: Test failed: data set to 'xx' instead of 'foobar' registry.c:122: Test failed: data_count set to 24 instead of 7 registry.c:123: Test failed: type 2 is not REG_SZ registry.c:134: Test failed: expected ERROR_SUCCESS, got 234 registry.c:135: Test failed: val_count set to 20 instead of 4 registry.c:136: Test failed: data_count set to 24 instead of 7 registry.c:137: Test failed: type 2 is not REG_SZ registry.c:138: Test failed: value is 'xx' instead of Test registry.c:139: Test failed: data is 'xx' instead of foobar registry.c:155: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) registry.c:156: Test failed: type 2 is not REG_SZ registry.c:169: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) registry.c:170: Test failed: type 2 is not REG_SZ registry.c:182: Test failed: val_count set to 5 instead of 4 registry.c:183: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) registry.c:184: Test failed: type 2 is not REG_SZ registry.c:185: Test failed: value is not 'Test' registry.c:195: Test failed: expected ERROR_SUCCESS, got 234 registry.c:196: Test failed: val_count set to 5 instead of 4 registry.c:197: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) registry.c:198: Test failed: type 2 is not REG_SZ registry.c:199: Test failed: value is not 'Test' registry.c:200: Test failed: data is not 'foobar' At this point it seems to stop responding and advapi32_test.exe is eating 99% CPU. Of course it could be my system that is in error. I then ran the tests on my laptop, running WinXP home edition. I receive only 3 errors there. The output follows. C:\winetests>advapi32_test.exe registry registry.c:96: Test failed: value set to 'xx' instead of 'Te' registry.c:97: Test failed: data set to 'xxx' instead of 'foobar' registry.c:111: Test failed: data set to 'xxx' instead of 'foobar' registry: 56 tests executed, 0 marked as todo, 3 failures. Note that I downloaded new test binaries for these tests after finding the test hung on WinXP Pro. This did not seem to have any effect on the results. At 05:39 PM 12/11/2002 +1100, you wrote: Hi, I ran the advapi32_test registry again today, and only received 3 errors: h:\wine\wine\dlls\advapi32\tests\registry.c:96: Test failed: value set to 'xx' instead of 'Te' h:\wine\wine\dlls\advapi32\tests\registry.c:97: Test failed: data set to 'xxx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:111: Test failed: data set to 'xxx' instead of 'foobar' This seems very strange to me. I ran the test at first because I thought it might have been a matter of long file names, but then when I moved it back I found it wasn't, there was just something weird happening instead. I'll try to reproduce the other errors tonight if I can, and if I am successful I will post the results to the wine-devel group. David Miller, you also received 31 errors for this test, yes? Could you test again straight after a computer reboot? Thanks, Kye Lewis You can reach me at: [EMAIL PROTECTED] at most times [EMAIL PROTECTED] from 9am to 3pm Monday to Friday [EMAIL PROTECTED] is an alternative email
Re: Win2000 Conformance Test Results...
Hi Just ran the same tests, reported results where different. Maybe this will help debugging... David Kye Lewis wrote: advapi32_test registry: 56 tests executed, 0 marked as todo, 0 failures. kernel32_test alloc: 58 tests executed, 0 marked as todo, 0 failures. atom: 229398 tests executed, 0 marked as todo, 0 failures. codepage: 2 tests executed, 0 marked as todo, 0 failures. directory: 48 tests executed, 0 marked as todo, 0 failures. drive: 160 tests executed, 0 marked as todo, 0 failures. I get drive: 158 tests executed, 0 marked as todo, 0 failures. Hmmm... are we using different versions of the tests? I'm using http://fgouget.free.fr/wine/winetests.zip, ls -l and m5sum -rw-rw-r--1 shareshare 672352 Dec 9 23:25 winetests.zip b69f703ee7f71ef8a9bd4114828394ab winetests.zip which doesn't seem to have changed (downloaded it again) environ: 39 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\file.c:578: Test failed: DeleteFile should fail with an empty path, and last error value should be ERROR_FILE_NOT_FOUND h:\wine\wine\dlls\kernel\tests\file.c:610:Current offset = 0015 h:\wine\wine\dlls\kernel\tests\file.c:635:Current offset = 0015 file: 487238 tests executed, 0 marked as todo, 1 failure. format_msg: 58 tests executed, 0 marked as todo, 0 failures. locale: 54 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\path.c:927:TMP=C:\WINNT\TEMP h:\wine\wine\dlls\kernel\tests\path.c:935:TMP=C:\WINNT h:\wine\wine\dlls\kernel\tests\path.c:944:TMP=C:\ h:\wine\wine\dlls\kernel\tests\path.c:954:TMP=C: h:\wine\wine\dlls\kernel\tests\path.c:822: Test failed: win2000 BUG:expected 10, got 11 h:\wine\wine\dlls\kernel\tests\path.c:834: Test failed: win2000 BUG:expected 10, got 11 h:\wine\wine\dlls\kernel\tests\path.c:848: Test failed: win2000 BUG:expected 10, got 11 h:\wine\wine\dlls\kernel\tests\path.c:879: Test failed: win2000 BUG:expected 10, got 11 h:\wine\wine\dlls\kernel\tests\path.c:892: Test failed: win2000 BUG:expected 10, got 11 h:\wine\wine\dlls\kernel\tests\path.c:898: Test failed: win2000 BUG:should return path without terminating back slash path: 2083 tests executed, 0 marked as todo, 6 failures. for kernel32_test path, I got this additional error (before all the others) h:\wine\wine\dlls\kernel\tests\path.c:517: Test failed: GetLongPathNameA: wrong returncode, 105 instead of 105 h:\wine\wine\dlls\kernel\tests\process.c:374: Test failed:StartupInfoA:lpDesktop expected (null), got WinSta0\Default h:\wine\wine\dlls\kernel\tests\process.c:375: Test failed:StartupInfoA:lpTitle expected (null), got C:\DOCUME~1\KYELEW~1\DESKTOP\WINETE~1\KERNEL32_TEST.exe h:\wine\wine\dlls\kernel\tests\process.c:450: Test failed:StartupInfoA:lpDesktop expected (null), got WinSta0\Default h:\wine\wine\dlls\kernel\tests\process.c:527: Test failed:StartupInfoA:lpTitle expected (null), got C:\DOCUME~1\KYELEW~1\DESKTOP\WINETE~1\KERNEL32_TEST.exe process: 116 tests executed, 0 marked as todo, 4 failures. Exactly the same except I have 10 messages interspersed with these, saying: tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. Why these extra messages? thread: 112 tests executed, 0 marked as todo, 0 failures. msvcrt_test Test will not run Yup, gives a GPF. netapi32_test h:\wine\wine\dlls\netapi32\tests\access.c:95: Test failed: Bad Network Path access: 23 tests executed, 0 marked as todo, 1 failure. apibuf: 15 tests executed, 0 marked as todo, 0 failures. wksta: 14 tests executed, 0 marked as todo, 0 failures. rpcrt4_test rpc: 901 tests executed, 0 marked as todo, 0 failures. shell32_test generated: 272 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\shell32\tests\shlfileop.c:286: Test failed: Files are copied to other directory h:\wine\wine\dlls\shell32\tests\shlfileop.c:287: Test failed: The file is copied shlfileop: 121 tests executed, 0 marked as todo, 2 failures. shlwapi_test clist: 236 tests executed, 0 marked as todo, 0 failures. Here I get two failures: h:\wine\wine\dlls\shlwapi\tests\clist.c:367: Test failed: allowed bad element size h:\wine\wine\dlls\shlwapi\tests\clist.c:372: Test failed: allowed adding a container generated: 19 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\shlwapi\tests\shreg.c:79: Test failed: RegCreateKeyA failed h:\wine\wine\dlls\shlwapi\tests\shreg.c:105: Test failed: SHGetValueA failed h:\wine\wine\dlls\shlwapi\tests\shreg.c:106: Test failed: (0123456789,bar\subdir1) h:\wine\wine\dlls\shlwapi\tests\shreg.c:107: Test failed: () h:\wine\wine\dlls\shlwapi\tests\shreg.c:112: Test failed: SHGetValueA failed h:\wine\wine\dlls\shlwapi\tests\shreg.c:113: Test failed: (0123456789) h:\wine\wine\dlls\shlwapi\tests\shreg.c:114: Test failed: () h:\wine\wine\dlls\shlwapi\tests\shreg.c:140: Test failed: test4 RegOpenKey h:\wine\wine\dlls\shlwapi\tests\shreg.c
Re: MSI (MS Installer)
Uwe Bonnes wrote: It's not wine that needs msiexec, it's some application with it's installer. So this application has to care for msiexec. If things change and msiexec get's part of the ms core distribution, we can reconsider... Bye Actually it is included with Windows 2000, XP and Me etc: Windows® Installer is an installation and configuration service that reduces the total cost of ownership. The installer ships with Microsoft® Windows® .NET Server 2003 family, Windows® XP, Windows® 2000, and Windows® Millennium Edition (Windows® Me). The installer is also provided as a service pack to Microsoft® Windows NT® version 4.0., Windows® 98, and Windows® 95. (from http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp) Although it depends what you call the ms core distribution I guess... David
WinXP Professional conformance test results
These tests were completed individually on WinXP Pro using the binaries from here: http://fgouget.free.fr/wine/winetests.zip C:\winetests>advapi32_test.exe registry h:\wine\wine\dlls\advapi32\tests\registry.c:80: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:81: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:94: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:95: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:96: Test failed: value set to 'xx' instead of 'Te' h:\wine\wine\dlls\advapi32\tests\registry.c:97: Test failed: data set to 'xx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:108: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:109: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:111: Test failed: data set to 'xx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:122: Test failed: data_count set to24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:123: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:134: Test failed: expected ERROR_SUCCESS, got 234 h:\wine\wine\dlls\advapi32\tests\registry.c:135: Test failed: val_count set to 20 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:136: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:137: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:138: Test failed: value is 'xx' instead of Test h:\wine\wine\dlls\advapi32\tests\registry.c:139: Test failed: data is 'xx' instead of foobar h:\wine\wine\dlls\advapi32\tests\registry.c:155: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:156: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:169: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:170: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:182: Test failed: val_count set to 5 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:183: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:184: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:185: Test failed: value is not 'Test' h:\wine\wine\dlls\advapi32\tests\registry.c:195: Test failed: expected ERROR_SUCCESS, got 234 h:\wine\wine\dlls\advapi32\tests\registry.c:196: Test failed: val_count set to 5 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:197: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:198: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:199: Test failed: value is not 'Test' h:\wine\wine\dlls\advapi32\tests\registry.c:200: Test failed: data is not 'foobar' registry: 56 tests executed, 0 marked as todo, 31 failures. C:\winetests>kernel32_test.exe alloc alloc: 58 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe atom atom: 229398 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe codepage codepage: 2 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe directory directory: 48 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe drive drive: 158 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe environ environ: 39 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe file h:\wine\wine\dlls\kernel\tests\file.c:578: Test failed: DeleteFile should fail with an empty path, and last error value should be ERROR_FILE_NOT_FOUND h:\wine\wine\dlls\kernel\tests\file.c:610:Current offset = 0015 h:\wine\wine\dlls\kernel\tests\file.c:635:Current offset = 0015 file: 487238 tests executed, 0 marked as todo, 1 failure. C:\winetests>kernel32_test.exe format_msg format_msg: 58 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe locale locale: 54 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe path h:\wine\wine\dlls\kernel\tests\path.c:517: Test failed: GetLongPathNameA: wrong return code, 104 instead of 44 h:\wine\wine\dlls\kernel\tests\path.c:927:TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp h:\wine\wine\dlls\kernel\tests\path.c:935:TMP=C:\WINDOWS h:\wine\wine\dlls\kernel\tests\path.c:944:TMP=C:\ h:\wine\wine\dlls\kernel\tests\path.c:954:TMP=C: h:\wine\wine\dlls\kernel\tests\path.c:879: Test failed: win2000 BUG: expected 12, got 13 h:\wine\wine\dlls\kernel\tests\path.c:892: Test failed: win2000 BUG: expected 12, got 13 h:\wine\wine\dlls\kernel\tests\path.c:898: Test failed: win2000 BUG: should return path without terminating back slas
Re: Janitorial Projects -- conformance tests --recruiting volunteers
As someone only attempting to learn C I am looking for some other way to contribute something to wine. I have WinXP home on my laptop, so I could do WinXP tests if you can give me more information on what needs to be done. Dave
Re: Janitorial Projects -- conformance tests --recruiting volunteers
I could probably run some tests under WinXP. I just need to compile the tests on windows, execute them, and post output to wine-devel? Is this correct?
Re: Fwd: Re: [putty]Winelib support + patch
> > http://chiharu.haun.org/peace/ > > As far as I can tell, this is only a PE loader, so you need to > cross-compile everything as PE dlls. What we would want for Wine is an > ELF loader that can also load PE and seamlessly link binaries of both > types together. I've not read the URL above, but have looked at the netbsd ld.elf_so, making it do something subtly different with other object formats shouldn't be too hard - it of only boring (system) code. You might want to make the wine binary use a non-standard ELF interpreter, the name of the program used to do all the library loading and symbol fixupnis a property of the program being run, not of the system. Do if you need a pe_open (cf dlopen) it shouldn't be too hard to sort out. Although the different OS will have different requirements on the ELF interpreter, it is the ELF object format that requires it. In particular the rules for looking up symbols are easily changed. David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> With gcc 3.2? That compiler optimizes the jmp away in an if statement, > apparently assuming that the "if" clause is executed much more often. > The "else" clause, OTOH, jmp's to the end of the subroutine and jumps > back afterwards. Thus if the compiler guesses wrongly, the CPU'll have > to do two more jmp's per loop, with possible instruction cache miss. > Hard for me to believe that'll be a speed improvement on any CPU. If the > compiler guesses right, 1 jmp will be saved per loop. Actually 2.95.3 which doesn't seem to want to generate a loop with only one taken branch. Something must make the conditional forward jump be faster than the unconditional one. And yes, I couldn't believe it either :-) David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> Other observations: > * my naive strcpy/strcat implementation seems more efficient than the > one in the glibc! That's pretty weird. Probably because the glibc routines are heavily optimised for long strings. I did a load of experiments with different versions of memcpy, the instruction setup cost of 'rep movsl' is such that it is faster not to use it for copies of (IIRC) 180 bytes on my athlon. The 'rep movsb' used to copy the trailing bytes is definitely wasteful. > * cpycat is much more efficient in this type of scenario. That's not > very surprising of course. Why does the C library have such braindead > functions as strcpy and strcat? Probably goes back into the annals of Unix history. My guess is that the return value wasn't defined, but happened to be the destination buffer address on one of the first implementations. Some code used the fact and no one dared change it Probably similar to asking why the priority of | and == are backwards. (K/R didn't want to change any code when they invented ||.) David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> > It is as if the code from your program is executing far > > slower than anything from libc! > > That is very well possible if he has the right libc. Take a look at the > optimizations in the string functions in glibc, and you'll have an idea > why. Unless you are a assembler programming Guru for a certain > architecture, you'll have a hard time beating them. I'm a fairly good assembler programmer Actually I don't have glibc - I'm running netbsd not linux. Netbsd might benefit from faster strxxx routines. OTOH the times are very dependant on the cpu model! My slotA athlon 700 executes my str_add() faster the way I coded it - I tried the other order and it sucked. Similarly escaping with: lim[-1] = 0; return lim; didn't help. Of course you can use the same tricks as glibc does to speed up your own variant of the copy routine. David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> > And in any case the right approach to writing > > correct and secure code is not to truncate every string in sight to > > some fixed buffer size; it's to make sure you allocate buffers of the > > right size, and then you can use standard strcpy/strcat/sprintf/etc. > > without worrying about lengths. Yes, you can use a small (on stack) buffer for the 'usual' case and only allocate a large one in the unusual ones. (but don't use alloca()...) > I think this statement has to be tightened. I am sure you know exactly what > you mean, Alexandre, and I believe that I and many others do. However I > think we need to mention that one needs to consider that the strings passed > in may be bad, e.g. unterminated. Either one uses that actual measured > lengths of the strings when allocating or one checks the lengths of the > strings against the allocated space. Yes, but even then strcpy may not be safe! Another thread could change the length after you've counted it. > In particular one DOES NOT allocate on > the basis of some wishy-washy documentation statement or a hard-coded > constant that the caller may well have ignored. Absolutely! David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> optimizations: -O2
strcpy/cat sprintf snprintf str_add stpcpy
>2.926220 1.427674 1.408928 3.405458 0.892890 1000
>2.622081 1.308464 1.292384 3.062085 0.867009 900
>2.363464 1.169335 1.152487 2.727685 0.740690 800
These do not look right, in particular the first column is too fast.
For instance my system gives (NUM_ITER=1000):
0.174988 0.042060 0.042097 0.057267 1000
0.155118 0.038678 0.038592 0.051500 900
0.138036 0.034586 0.034597 0.045832 800
...
0.005573 0.006449 0.006452 0.00210330
0.003858 0.005962 0.005964 0.00153620
0.002163 0.005783 0.005802 0.00096710
It is as if the code from your program is executing far
slower than anything from libc!
David
--
David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static func), or in > some library that will be linked (statically, I hope). Ideas? Inlining them would (probably) be bad news. They are not a completely trivial size (ie smaller than the call sequence) and they are more likely to be resident in the Icache if they are functions. They are useful though, and do what the programmer wanted (unlike strncpy whose only point is that it doesn't overrun the target buffer). However in this case they aren't quite right! len = strlcpy(buf, s0, buflen); len += strlcpy(buf + len, s1, buflen - len) len += strlcpy(buf + len, s2, buflen - len) is slightly more complex than using my str_add(). The source for the functions can be grabbed from netbsd or freebsd. David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> With higher O values, the difference becomes bigger, but I'm not sure > then that some of the operations are not optimized out of the process, > which makes the entire benchmark useless. I don't think they would be, and it is easy enough to check (objdump -d way1). Benchmarking is meaningless if you don't use the optimisation level then will be used in real life. Also the compiler is really designed to be used with -O, the code generatd without it is only 'half cooked'. > Do we go for David's suggestion, that is more efficient, but is also > more cubersome and requires two extra vars to implement right? The extra variables are likely to be well optimised by the compiler. strlcpy/cat will be even slower than the strcpy/cat versions. way1:900 ms way1a: 1321(strlcpy/cat) way2:721 ms way3:322 ms way3a: 223 ms (without bound check) David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> probably that > you were underestimating the time required to parse the format string, > which is probably greater than anything else. Everything else is simple > searching and copying whereas the parsing is probably at least a > quadratic-order function. No it will be linear (on the length of the format string). But just rather more expensive than you probably expect. There is a lot of red tape lurking. David -- David Laight: [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
Shachar Shemesh wrote: Benchmark will follow soon. In the mean time, think about the fact that, compared to linear copying of the strings in, these are the overheads (neglecting function call overhead, which is not neglectible but is fair): n - number of strings in the final string m(i) - length of string i (0 sm(i) - sigma of all lengths up to i (0 sm(n) - total length of all strings with sprintf - parsing the format string*n+sm(n) with strcpy+strcat - for each strcat we have to find the end of the string (sm(i-1)), and then write our own string (m(i)). Shachar Shemesh wrote: When I'm wrong, I'm wrong. sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 sun@sun:~/sources/wine/test$ ./way1 Operation took 0 seconds 450763 usec sun@sun:~/sources/wine/test$ ./way2 Operation took 0 seconds 598408 usec sun@sun:~/sources/wine/test$ ./way3 Operation took 0 seconds 427037 usec Was going to say earlier, but didn't get to it ... the reason is probably that you were underestimating the time required to parse the format string, which is probably greater than anything else. Everything else is simple searching and copying whereas the parsing is probably at least a quadratic-order function. Anyway you've now demonstrated that so this isn't that relevant anymore... David
Wine REALLY emulates Windows (was: Texture corruption in Wine)
I am continually amazed at how well Wine emulates Windows - for example, my recent experiences show Wine has the whole "Just re-install it, it will fix it" thing down pat! 8^> To recap the story thus far - Several months ago, I was able to play Halflife- Opposing force all the way through under Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows "mysterious changes" thing down pat! But it works. As Bugs Bunny said, "I don't ask questions, I just have fun." So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it
Re: DIB engine
Hi Hetz, Just a few clarifications. The TransGaming DIBengine doesn't use SDL, and it was written mostly by Jonathan Meunier with help from Gav, Peter and myself. Anyhow, I believe Johan Gill is aware that we have the dibengine, and is in fact probably refering to it (as I have had private correspondence with him) For those who don't follow this list all the time, more information can be found in these two threads: http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html and http://www.winehq.com/hypermail/wine-devel/2002/11/0849.html Cheers David On Mon, 2 Dec 2002 08:17, Hetz Ben Hamo wrote: > Hi, > > Before you re-invent the wheel - David (forgot his family name, sorry > David) from Transgaming (if I'm not mistaken) has started to work on a DIB > engine that uses SDL, so you might want to collaborate with him on his > engine.. > > This reminds me a question: Is there a way that instead of using the DIB > engine, to create an RDP events and show them in an application like > rdesktop? > > Thanks, > Hetz > > On Sunday 01 December 2002 22:52, Johan Gill wrote: > > Hi all, I've just started working on the DIB engine, FYI. > > -- > > Johan Gill, [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
> I said that due to the wall to wall agreement over the superiority of
> sprintf/snprintf. If there is a consensus, we should stick to it.
But the performance of it will suck badly.
Something like:
char *
str_add(char *s, char *lim, const char *a)
{
int c;
do {
if (s >= lim) {
s = lim - 1;
c = 0;
} else
c = *a++;
*s++ = c;
} while (c);
return s;
}
So you can do:
lim = buf + len;
buf = str_add(buf, lim, "abc");
buf = str_add(buf, lim, "123");
...
might be safer.
David
--
David Laight: [EMAIL PROTECTED]
Re: Texture problems under Wine - more info
Lionel Ulmer wrote: '> This begs the question: > Does the Linux implementation of pthread really work anyway? Considering that about 2 months ago, I was able to play HalfLife Opposing Force all the way through under Wine, I doubt the pthread emulation is a problem. By the way, what drivers are you using ? XFree86 DRI for Radeon 7500 (r100 driver) from CVS. I haven't had time to begin regressing the OpenGL shim under Wine, as this weekend has been rather busy doing other things, but as I get time I will begin doing so.
Texture problems under Wine - more info
As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.
Re: compiling wineserver under cygwin - thread context
Dimitrie O. Paun wrote:
On November 28, 2002 09:51 am, David Fraser wrote:
So part of the question is, in order to get Wine to function properly on
Cygwin, what is the right
threading approach to take? Am I right in thinking that the current code
wouldn't work on Cygwin?
I say, let's get the compiling and linking working, and then worry about
actually running it... :)
As far as I can see the only places get_thread_context and
set_thread_context are used is in
scheduler/thread.c, to implement WINAPI GetThreadContext and
SetThreadContext
So actually a first approximation for [sg]et_thread_context for
Cygwin would be one that does nothing. Then we can try submitting
patches to Cygwin (Approach 2), so that other apps can make use
of ptrace, if necessary.
OK, done that. So now wineserver.exe actually links :-) And it runs too!
However can't yet see whether its going to do anything as in order to
actually run programs
it looks like we need tolink miscemu/main.c
Problem here being that it wants to link with ntdll, which doesn't build
yet.
That still needs a lot more work... In the mean time a very simple patch
that
does nothing for context_i386.c is below in case anyone else wants to try...
David
Index: server/context_i386.c
===
RCS file: /home/wine/wine/server/context_i386.c,v
retrieving revision 1.24
diff -u -r1.24 context_i386.c
--- server/context_i386.c 8 Nov 2002 18:55:31 - 1.24
+++ server/context_i386.c 28 Nov 2002 15:48:01 -
@@ -76,7 +76,24 @@
#define PTRACE_SETDBREGS PT_SETDBREGS
#endif
-#ifdef linux
+#if defined(__CYGWIN__)
+
+/* retrieve a thread context */
+static void get_thread_context( struct thread *thread, unsigned int
flags, CONTEXT *context )
+{
+/* FIXME: implement this */
+file_set_error();
+}
+
+
+/* set a thread context */
+static void set_thread_context( struct thread *thread, unsigned int
flags, const CONTEXT *context )
+{
+/* FIXME: implement this */
+file_set_error();
+}
+
+#elif defined(linux)
#ifdef HAVE_SYS_USER_H
# include
#endif
Re: compiling wineserver under cygwin - thread context
David Fraser wrote: The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform. Basically there's some code that does the threading stuff which is platform-specific. There are Linux and BSD and Sun variants, none of which work under cygwin ... Basically sys/ptrace.h is what's missing. This lets the process interrupt a child process and get/set its registers. Does anyone have any idea what the best way to write a replacement for cygwin would be? Maybe I need to ask the cygwin list. After some more investigating ... Dimi added a request for ptrace support in cygwin in November 2000: http://cygwin.com//cgi-bin/cygwin-todo.cgi?20001120.094813 But I can't see anything that's been done about it. So I thought I would clarify here exactly what should be done before trying to do it... The platform-specific bits define the functions get_thread_context and set_thread_context which each use ptrace (in the existing platforms) to get / set registers for that thread. The requests given to ptrace are: PTRACE_PEEKUSER / PTRACE_POKEUSER (for getting / setting debugging registers) PTRACE_GETREGS / PTRACE_SETREGS (for getting / setting general registers) PTRACE_GETFPREGS (for getting / setting floating point registers) so it's fairly simple... As far as I can see the only places get_thread_context and set_thread_context are used is in scheduler/thread.c, to implement WINAPI GetThreadContext and SetThreadContext Now from reading through the sources Wine uses clone() to create threads, using its own implementation of clone for linux if not available that looks like it wouldn't work with cygwin... Cygwin has a pthreads implementation that maps onto the Windows Thread functions. So part of the question is, in order to get Wine to function properly on Cygwin, what is the right threading approach to take? Am I right in thinking that the current code wouldn't work on Cygwin? Approach 1 would be to simply call the Windows Thread functions from Wine if compiled on Cygwin That would involve the nastiness of including the w32api headers... Approach 2 would be to just use the Windows GetThreadContext/SetThreadContext functions, since they're just looking at registers etc. These could then be wrapped up in an (incomplete) ptrace implementation for cygwin, which we would call. Approach 3 would be to reimplement the appropriate parts of ptrace for cygwin in some other way. I'm guessing Approach 2 is right. Anyway any advice would be appreciated David
Re: [RFC] Winelib enhancements
Martin Wilck wrote: Am Don, 2002-11-28 um 07.35 schrieb Dimitrie O. Paun: -CC=gcc +CC=wcc -RC=windres +RC=wrc I can't follow you here. You seem to have been porting Applications using Unix-Style Makefiles. I'd guess the vast majority of Applications comes with Windows VC++ "project files" (.dsp) and "workspaces" (.dsw). This is probably true, although a lot of the already-portable open source applications like Mozilla that Dimi's thinking of can use Unix-Style Makefiles as well. In any case, IMO this is what's winemaker is all about. Your idea of introducing compatibility tools is nice but somewhat limited in scope. What we really need is a much more intelligent winemaker. What would be really nice is if the new intelligent winemaker produced a Makefile, rather than doing the actual build. That way it would be less opaque to debug any problems as you could see exactly what the make was doing, and alter it if necessary. It also means people won't have to keep on using VC++. Or does winemaker do this already? David
