Cabinet.dll documentation
Hello Are the cabinet stuctures and defines documented anywhere online? I tried to submit the WINE headers to mingw for use in w32api but they couldnt find documents on it anywhere. All I could find was the cabinet SDK and they has a EULA attached so I am not looking at it. Thanks Steven __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
comdlg32 16/32 split and TWEAK_WineLook
Hello all,
I am looking at splitting the rest of the Win16/32 code in commdlg32 and am having a
few problems.
I have come across a lot of code that is marked FIXME: TWEAK_WineLook. I need to split
out the
32to16 resource converions and fix this but am unsure what would be the correct route.
Can we
disable/remove the TWEAK_WineLook for the Win32 code? I dont understand why the
implementation of
Win32 filedialog functions needs to support the old 3.11 look. If we remove the old
3.1 look from
the Win32 stuff then I think I can split the internal FILEDLG_* functions.
Here is a bit of the code in question:
BOOL newlook = TRUE; /* FIXME: TWEAK_WineLook */
COMDLG32_SetCommDlgExtendedError(0);
/* some flags don't allow to match the TWEAK_WineLook */
if (ofn-Flags (OFN_ALLOWMULTISELECT|OFN_ENABLEHOOK|OFN_ENABLETEMPLATE))
{
newlook = (ofn-Flags OFN_EXPLORER) ? TRUE : FALSE;
}
if (newlook)
{
return GetFileDialog95W(ofn, OPEN_DIALOG);
}
else
{
return GetFileName31W(ofn, OPEN_DIALOG);
}
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Problems building dlls for use with winelib
Hi, compiling and linking my application against Winelib now works fine. However, loading the application with wine myapp.exe.so fails, with the following errors: err:module:load_library can't load test1.dll err:module:load_library can't load test2.dll Error while processing initial modules Could you give me a hint where to look for the problem? Cheers, Martin __ Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter, Adressverifizierung, digitale Unterschrift: http://freemail.web.de
Re: Conformance tests (resent)
On Tue, 26 Aug 2003, Ferenc Wagner wrote: Francois Gouget [EMAIL PROTECTED] writes: You suggested a script to generate a zip file automatically. I have a couple of trivial scripts that should do 90% of the job. * zipmsvctests Exactly what I envisioned. What do you think about putting it into the Wine CVS tree so that anyone compiling the tests could use it? Into tools/ for example? I would not mind but see below. * runtests.bat Maybe we could do a bit more here, like redirecting the output into a file and echoing back a counter between the tests as a kind of progress bar. Possibly but remember that batch files are erally restricted in what they can do. The batch file also has to run on both Win9x and NT*. I could probably write a Perl script to generate the above scripts, but I am not sure if it is wise to require Perl from the good soul trying to compile the tests for us. So maybe we are better including the results (as well) in the tree. I think that's the way to go. Anyone wishing to compile the tests with MSVC already needs to use perl scripts to generate the Visual Studio project files. These scripts could probably easily be modified to generate the above batch files too. That would be much more maintainable than putting hard-coded scripts into Wine. Then we would run the script on a Unix machine and upload them some place so that Windows users can get them and build without installing perl. All we need is to FIX the BUGS and then it will all be trivial to manage. Golden words! Yep, and it should not even be too hard since it's only the bugs in the tests that we need to fix in this case. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
--- Francois Gouget [EMAIL PROTECTED] wrote: Is there a way to use the registry (as seems to be required for many features) and still document our settings correctly? Maybe add a 'Doc' value for each regular value: [SomeKey] OptionFoo=1 OptionFooDoc=OptionFoo does this, that, etc. Better ideas? Kinda off topic. It sounds like a good idea and it might work for WINE but the Windows registry is a bloated mess. I have seen Windows registrys get to 40mb+. Adding more keys for documentation like this is just going to make the memory requirements higher and performance worse. If you wanted to go to a binary format, the ReactOS developers have offered to relicense the code we have as LGPL so you might be able to do this without much of a performance hit. Anyway I havent used WINE on *nix in a while so i dont know if this really is a issue but its something to think about. I am not sure about the compression and performance numbers so it might not be a issue for WINE at this point. Thanks Steven __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
On Thu, 28 Aug 2003, Steven Edwards wrote: [...] It sounds like a good idea and it might work for WINE but the Windows registry is a bloated mess. I have seen Windows registrys get to 40mb+. Adding more keys for documentation like this is just going to make the memory requirements higher and performance worse. True, registry size is an issue. On the other hand we would only add doc for the Wine configuration settings which should not be that numerous. So the size and performance impact should not be too bad (unless we get sloppy and add myriads of Wine settings). If you wanted to go to a binary format, the ReactOS developers have offered to relicense the code we have as LGPL so you might be able to do this without much of a performance hit. Anyway I havent used WINE on *nix in a while so i dont know if this really is a issue but its something to think about. I am not sure about the compression and performance numbers so it might not be a issue for WINE at this point. I think Wine will want to go towards a binary 'database-like' registry format eventually. One goal is to not have to load the whole registry on startup. This is especially useful when the registry is large like after installing MS Office or when using the Windows registry. The performance of loading the registry used to be abysmal but it was improved greatly a couple of years ago and since then it's not a big issue anymore. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: What happened to this patch?
On Thu, 28 Aug 2003, Ferenc Wagner wrote: http://www.winehq.com/hypermail/wine-patches/2002/12/0161.html It actually contains useful information. Meanwhile, I solved the missing urlmon problem by downloading it from http://programming.ccp14.ac.uk/ftp-mirror/programming/mingw32/home/janjaap/mingw32/platform-SDK/import_libs/liburlmon.a.gz but I do not know what I did. Anybody has an idea? The patch has been applied except for the part about Urlmon. Maybe because the proper solution is to send a patch to the MinGW people to add support for the urlmon library. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: the choice of a GNU generation
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
On Fri, 29 Aug 2003 01:49:51 +0200, Sir Francois Gouget scribed thus: The Unix way is to have text configuration files that are self-documented. Not all projects are born equal on this point of course, but look at squid.conf, smb.conf our even our own Wine configuration file for instance. We can always put info on what the settings do in the users guide. However, I think a lot of the more obscure options could simply be killed off. For instance, what is DirectSoundHEL, and why do I need to set it manually? Can that not be auto-detected, with sufficient cleverness? I'm a developer, and I still don't understand what it does, or why it needs to be set, Win32 is just too huge to understand all of it. Very few prefs for Wine are actually genuine user preferences. They are mostly settings that you need to tweak either for your environment, or to make apps run correctly. Both of those settings should ultimately go. thanks -mike
Re: Wine 0.9 progress
On August 28, 2003 06:30 pm, Jeremy Newman wrote: Sure, if that is the address you want for the list I can probably put it up tomorrow sometime. I just want to be very sure before I start work on it. Well, [EMAIL PROTECTED] is OK AFAICT. Are there better proposals? Not sure how you want to accomplish this, but integrating it into the site should not be hard, if the output is generated using the .template spec of the lostwages engine. If it need to be more dynamic than that, some PHP work will be involved. No need for PHP -- the page will be static HTML generated externally through a Perl script I'd guess. We'll have to figure a way of integrating the above list with such a script. I'm wondering if we don't need a DB in the middle, something like so: wine-tests-results -- parser -- DB -- generator -- .template Something like MySQL should do, but it's a non-trivial setup. We need to figure out a few things: -- how do we trigger the parser based on email comming in from the list. Maybe run it as a user, and have things done through procmail. -- Jeremy, are you OK with setting up a simple database for this stuff? If so, we need to figure out a schema. -- We need to run the generator either from time to time, or when the DB gets updated. Any preference? -- Once you have the .template, what does it need to happen to have it appear on WineHQ? -- Dimi.
Who says bill gates is a nice guy?
Have a look at this photo from Redmond, inside the microsoft campus;-) http://spazioinwind.libero.it/nonsolomicrosoft/windows.jpg
Who says bill gates is a nice guy? (New link)
http://spazioinwind.libero.it/nonsolomicrosoft/windows.html
Re: Wine 0.9 progress
On Fri, 2003-08-29 at 07:35, Dimitrie O. Paun wrote: On August 28, 2003 06:30 pm, Jeremy Newman wrote: Sure, if that is the address you want for the list I can probably put it up tomorrow sometime. I just want to be very sure before I start work on it. Well, [EMAIL PROTECTED] is OK AFAICT. Are there better proposals? Not sure how you want to accomplish this, but integrating it into the site should not be hard, if the output is generated using the .template spec of the lostwages engine. If it need to be more dynamic than that, some PHP work will be involved. No need for PHP -- the page will be static HTML generated externally through a Perl script I'd guess. We'll have to figure a way of integrating the above list with such a script. I'm wondering if we don't need a DB in the middle, something like so: wine-tests-results -- parser -- DB -- generator -- .template Something like MySQL should do, but it's a non-trivial setup. We need to figure out a few things: -- how do we trigger the parser based on email comming in from the list. Maybe run it as a user, and have things done through procmail. It can work similar to how the mailman works, you have the script parse from /etc/aliases. .procmail would work as well. -- Jeremy, are you OK with setting up a simple database for this stuff? If so, we need to figure out a schema. Mysql is already on the machine, so that is fine. My concern is DB bloat over time. Will this DB get out of control or will it remain a fixed size? -- We need to run the generator either from time to time, or when the DB gets updated. Any preference? Cron, or during the monthly build. Monthly build is preferred IMO. I'm jumpy about giving out any further shell access to the box. -- Once you have the .template, what does it need to happen to have it appear on WineHQ? Just needs to be in the templates/en dir somewhere, it can be another level deep as well. I can provide the full path to whoever writes this script. -- Jeremy Newman [EMAIL PROTECTED] CodeWeavers, Inc.
Re: Wine 0.9 progress
On 29 Aug 2003, Jeremy Newman wrote: -- Jeremy, are you OK with setting up a simple database for this stuff? If so, we need to figure out a schema. Mysql is already on the machine, so that is fine. My concern is DB bloat over time. Will this DB get out of control or will it remain a fixed size? I will grow, as new tests are added to the database. We can have a monthly cleanup task to get rid of old tests (and maybe remember some fun stats while we're at it). -- We need to run the generator either from time to time, or when the DB gets updated. Any preference? Cron, or during the monthly build. Monthly build is preferred IMO. I'm jumpy about giving out any further shell access to the box. There's no need for shell access -- we just need to trigger the scrip. Doing it once per month is a bit too seldom. We can run the script every day, and make it smart to not do anything if the DB has not been updated. This is easy to do. -- Once you have the .template, what does it need to happen to have it appear on WineHQ? Just needs to be in the templates/en dir somewhere, it can be another level deep as well. I can provide the full path to whoever writes this script. Perfect. As long as we don't have to put it in CVS, things are simple. The best would be for the script to just output to stdout, and you redirect that where you need to when you install it. -- Dimi.
Re: Wine 0.9 progress
Hello guys,
some machinery is already in place
(http://afavant.elte.hu/~wferi/wine). Actually I am not
sure we need a database or so. What I have in mind:
Whenever somebody compiles the tests (with a Samba mount it
does not matter whether cross- os MSVC) s/he runs the
ziptests Bash script to produce a tests.zip, and we collect
it somewhere tagged by the date, eg. 20030828.
People download it, do their job, and send the report to
the list.
If the report is identical (modulo a couple of lines which
contain the current working directory and similar -- just
egrep -v it) to another for the same build and Windows
version, we just acknowledge the name. If it is always the
case, then forget it. If not, we may need a subarchitecture
or a better egrep pattern, this is manual.
For a new set of data, we run the dissect Perl script, which
gives a summary and one report file for each test. No need
to rerun this ever.
The gather script assembles the summaries for the various
architectures into a summary table, with links to the small
report files. Rerun when a new architecture is added for
this build.
We can have on directory for each build tag (like 20030828),
and separate directories for each architecture in them.
gather dissect
works here works here
,- win95
|
,- 20030828 -+-- nt4.0
||
| `- XP
index.html -+
| ,- win98
||
`- 20030914 -+-- nt4.0
|
`- XP
We can also have a 'latest' directory which simply links to
the appropriate architecture subdirectories, and we can also
gather a summary there. All the pages are static, and you
can select on the main page.
Find the scripts attached. I do not really want to go
further until I know where/how they will run. The desing is
not finished :)
Feri.
#!/usr/bin/perl -w
$dummy=;
while () {
($dll,$dummy,$test) = split /[.:\s]/;
if (/not compiled/) {
@res=();
} else {
open OUT, ${dll}_${test}.txt;
TEST: while () {
print OUT;
if (/^$test: (\d+) tests executed, (\d+) marked as todo, (\d+)/) {
@res=($1,$2,$3);
last TEST;
}
}
close OUT;
}
print $dll:$test @res\n
}
#!/usr/bin/perl -w
#
# Parameters: architecture names. The program loads the summary.txt
# files from the corresponding (lowercase) directories.
#
# Copyright (C) 2003 Ferenc Wagner
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
foreach $arch (@ARGV) {
$archs{$arch}-{reports} = 1;
open ARCH, \L$arch\E.txt or die Can't open \L$arch\E.txt!;
while (ARCH) {
($test,@results) = split;
push @{$alltests{$test}},($arch);
$archs{$arch}-{$test} = [EMAIL PROTECTED];
}
close ARCH;
}
print EOF;
!doctype html PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
html
head
titleTests results/title
link href=../default.css rel=stylesheet type=text/css
meta http-equiv=Content-Type
content=text/html; charset=ISO-8859-1
meta name=Author
content=Ferenc Wágner
/head
body
table
thead
tr
thdll:test/th
EOF
while (($arch,$tests) = each %archs) {
print EOF;
th colspan=3a href=\L$arch\E/results.txt\$arch/a
(a href=\L$arch\E/reporters.txt$tests-{reports}/a)/th
EOF
}
print EOF;
/tr
/thead
tbody
EOF
foreach (sort (keys %alltests)) {
print EOF;
tr
td class=test$_/td
EOF
while (($arch,$tests) = each %archs) {
@results = @{$tests-{$_}};
if (! @results) {
print EOF;
td colspan=3not compiled/td
EOF
} else {
if ($results[2]==0) {
print EOF;
td class=pass$results[0]/td
td class=pass$results[1]/td
td class=pass$results[2]/td
EOF
} else {
($file = \L$arch\E/.$_..txt) =~s/:/_/;
print EOF;
td class=fail$results[0]/td
td class=fail$results[1]/td
td class=faila href=$file$results[2]/a/td
EOF
}
}
}
}
print EOF;
/tr
/tbody
/table
/body
/html
EOF
Re: listview expert required
On Sun, 24 Aug 2003 19:34:36 -0400, you wrote: On August 24, 2003 05:44 pm, Dimitrie O. Paun wrote: Yes, this patch broke selection drawing: http://www.winehq.org/hypermail/wine-cvs/2003/04/0243.html blushIt's my patch, mea culpa/blush. Yeah, at a second look, it was rather obvious what went wrong. ChangeLog Always setup the selection colour, not just in custom draw. Index: dlls/comctl32/listview.c === RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.357 diff -u -r1.357 listview.c --- dlls/comctl32/listview.c 24 Jul 2003 00:03:13 - 1.357 +++ dlls/comctl32/listview.c 24 Aug 2003 23:30:31 - Hi Dimitrie, This is causing a regression in newsbin pro. New postings are highlighted by a green background colour. With the patch the text in the second and higher columns is painted with a normal backgound colour instead of green. Selected rows are OK. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Wine 0.9 progress
On Fri, 29 Aug 2003, Dimitrie O. Paun wrote: On August 28, 2003 06:30 pm, Jeremy Newman wrote: Sure, if that is the address you want for the list I can probably put it up tomorrow sometime. I just want to be very sure before I start work on it. Well, [EMAIL PROTECTED] is OK AFAICT. Are there better proposals? [...] No need for PHP -- the page will be static HTML generated externally through a Perl script I'd guess. We'll have to figure a way of integrating the above list with such a script. I'm wondering if we don't need a DB in the middle, something like so: wine-tests-results -- parser -- DB -- generator -- .template Something like MySQL should do, but it's a non-trivial setup. Do we really need a C program, a new mailing list, automated result submission, generating HTML and now a database just so we have something that says: Test | Result --+- kernel32 | Passed msvcrt| Passed oleaut32 | Passed dsound| Passed ... This all seems very much over-engineered to me. I'd really like to see that kind of energy spent on fixing the tests so that they actually work on Windows. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: the choice of a GNU generation
Re: listview expert required
On Fri, 29 Aug 2003, Rein Klazes wrote: New postings are highlighted by a green background colour. With the patch the text in the second and higher columns is painted with a normal backgound colour instead of green. Selected rows are OK. OK, I think I know what the problem is, I'll fix it when I get home. -- Dimi.
Figuring runtime settings
I've been able to find a lot of pages on how to run debug commands when trying to run WinApps, but they all seem to be oriented towards programmers working on modifying the code. I'm not a programmer, so my work would be more towards trying to figure out what combination of native vs builtin DLLs to use, what other DLLs I need to track down, what registry entries to modify, etc. For example; one of the apps I'd need to figure out is eBay's TurboLister (sometimes known as TurtleLister or TurdLister; it's for posting ebay auctions). I know it needs MSIE, but beyond that it still has other problems. I managed to get the install to run under Crossover Office, but then it crashes about 1 minute into using it. So what I need is a site with information on how to kludge an installation to run some particular app.
Re: Figuring runtime settings
Maybe you're looking for this: http://appdb.winehq.com
Re: listview expert required
On Fri, 29 Aug 2003, Rein Klazes wrote: Hi Dimitrie, This is causing a regression in newsbin pro. New postings are highlighted by a green background colour. With the patch the text in the second and higher columns is painted with a normal backgound colour instead of green. Selected rows are OK. Can you give this a try please and tell me if it works: Index: dlls/comctl32/listview.c === RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.359 diff -u -r1.359 listview.c --- dlls/comctl32/listview.c25 Aug 2003 23:44:51 - 1.359 +++ dlls/comctl32/listview.c29 Aug 2003 20:13:33 - @@ -3565,7 +3565,8 @@ cdsubitemmode = notify_customdraw(infoPtr, CDDS_PREPAINT, nmlvcd); if (nSubItem == 0) infoPtr-cditemmode = cdsubitemmode; if (cdsubitemmode CDRF_SKIPDEFAULT) goto postpaint; -prepaint_setup(infoPtr, hdc, nmlvcd); +if (nSubItem == 0 || (cdmode CDRF_NOTIFYITEMDRAW)) +prepaint_setup(infoPtr, hdc, nmlvcd); /* in full row select, subitems, will just use main item's colors */ if (nSubItem uView == LVS_REPORT (infoPtr-dwLvExStyle LVS_EX_FULLROWSELECT)) Thanks! -- Dimi.
Re: Wine 0.9 progress
Probably a batch script that runs all the tests and outputs the results to a file can do, but this a C program, a new mailing list, automated result submission, generating HTML and now a database for something that says: Test | Result --+- kernel32 | Passed msvcrt| Passed oleaut32 | Passed dsound| Passed seems a big exaggeration
Re: Wine 0.9 progress
Francois Gouget [EMAIL PROTECTED] writes: Do we really need a C program, a new mailing list, automated result submission, generating HTML and now a database just so we have something that says: Test | Result --+- kernel32 | Passed msvcrt| Passed oleaut32 | Passed dsound| Passed ... We want a little bit more than this... but I think you are right. This all seems very much over-engineered to me. I'd really like to see that kind of energy spent on fixing the tests so that they actually work on Windows. I would like to. I spent some patches against the tests, and they were refused because somebody remembered something. Now I need FACTS, and since nobody seemed to provide me with facts, I try to do something about that. I still can not say that results are pouring in :) Now I also produced Makefiles, by the way... Feri.
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
--- Todd Vierling [EMAIL PROTECTED] wrote: On Thu, 28 Aug 2003, Alexandre Julliard wrote: : I have a feeling we're just on different mental wavelengths here. : MAP_TRYFIXED is not an optional feature. If the #define exists, the feature : exists -- for the OS version used to compile, and all later versions. : : You are still thinking only about source distributions. The problem is : when you want to ship a binary: the only way to build a binary that : works for everybody is to build it on an old OS version; Yes, that's right. This is not a problem, as 99% of Wine users on NetBSD are building from source. The very small remainder of prebuilt-binary users can easily be told to ensure that the OS version is up-to-date (since there are security fixes that necessitate this anyway). : With a run-time check you don't have to sacrifice anything, You have to bend over backwards to do the runtime check, and you sacrifice *maintainability* with the extra normally-dead code added to Wine. I don't see a need to jump through extra hoops in this case. Shouldnt something like this added to the loader work for a runtime check? (note im not using proper function names or anything, just an example) if (running_on_netbsd version = first_version_that_supports_MAP_TRYFIXED) #define can_use_MAP_TRYFIXED Im no expert on NetBSD but I would think a simple check like that would suffice, and since it is in the loader, it would make it a runtime check, no? = -- Dustin Navea Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
