Re: Bug 469 - Application can not read from serial port
As of two month ago I had a problem with asynch reading from serial port. Synchronous reading worked. Don't know if it indeed fixed or not (don't have access to the hardware and software anymore). Vitaliy Tuesday, May 24, 2005, 11:40:29 PM, you wrote: > Hey guys, this one was (obviously) reported a while back, and the > offending patch was found a while back as well, but it appears that mike > (at codeweavers dot com) never was able to get around to it.. > Basically it is an issue that a solar panel reading application cant > retrieve information via the serial port. I have requested that someone > test it (the demo of the app is attached to the bug) on a recent wine > build. So hopefully it is working now, and if not, maybe it will be > trivial? Either way, the name of the program looks to be SunGoXL, and > perhaps there is a more recent version of the program that allows it to > run in wine, if the older one doesn't work. > The changelog for the patch is: > cvs log files/file.c > Mike McCormack <[EMAIL PROTECTED]> > Read data immediately in overlapped ReadFile if possible. > From the most recent traces we have that show the problem, it looks as > though the GetOverlappedResult function is waiting on something > (probably the solar equipment) to be returned, but it never does, so > maybe at the time (if not still now) wine was unable to use the serial > port for whatever reason? > Other people could test the program, but if it is something to do with > serial communication with solar equipment, it wouldn't make any sense, > unless that someone else has the same equipment and issue... Maybe the > reporter still checks that email, and can test it out... > If theres no activity on the bug in 1 month, I will resolve it abandoned.. > Dustin
Bug 469 - Application can not read from serial port
Hey guys, this one was (obviously) reported a while back, and the offending patch was found a while back as well, but it appears that mike (at codeweavers dot com) never was able to get around to it.. Basically it is an issue that a solar panel reading application cant retrieve information via the serial port. I have requested that someone test it (the demo of the app is attached to the bug) on a recent wine build. So hopefully it is working now, and if not, maybe it will be trivial? Either way, the name of the program looks to be SunGoXL, and perhaps there is a more recent version of the program that allows it to run in wine, if the older one doesn't work. The changelog for the patch is: cvs log files/file.c Mike McCormack <[EMAIL PROTECTED]> Read data immediately in overlapped ReadFile if possible. From the most recent traces we have that show the problem, it looks as though the GetOverlappedResult function is waiting on something (probably the solar equipment) to be returned, but it never does, so maybe at the time (if not still now) wine was unable to use the serial port for whatever reason? Other people could test the program, but if it is something to do with serial communication with solar equipment, it wouldn't make any sense, unless that someone else has the same equipment and issue... Maybe the reporter still checks that email, and can test it out... If theres no activity on the bug in 1 month, I will resolve it abandoned.. Dustin
Bug 2977 - Homeworld 2 wont launch
Hey guys, this bug was reported, but recently (without updating wine from what I can tell), the reporter updated the kernel with yum.. After doing so, the game launches perfectly (except for the copy protection getting in the way).. Any comments on why this might happen? The reporter should be subscribing shortly, so he can probably post info about it. Dustin
Re: Translate the WineFAQ to French (gettext)
On Wed, 2005-05-25 at 02:15 +0200, Francois Gouget wrote: > So there's really no point to focus on Locale::gettext.pm. You are right, all these dependencies are crazy. First, perl modules are evil. They are outside the packaging system, and I had only pain and suffering from them. Second, if there are no neat Fedora Code 3 .rpm package available, it doesn't exist as far as I'm concerned. Third, the SGML tools are already a big pain. Multiplying it 10 fold is not a step forward. We need to find a way to deal with this, and I'd much rather have a self-contained po4a. This is a tough one. Is there any way we can get the number of dependencies to a sane level? (And that level being that it consists of a few packages that are readily available for most distros) -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: Release notes
On Wed, 2005-05-25 at 00:43 +0100, Mike Hearn wrote: > Thoughts? Go for it! We can see how well it works over the next couple of month. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: Translate the WineFAQ to French (gettext)
Detlef Riekenberg wrote: Am Montag, den 23.05.2005, 13:18 +0200 schrieb Francois Gouget: Can we easily patch it to get rid of it? We don't need localized messages, maybe we can provide a dummy gettext.pm? For the winetools shell-script, i use this function, ... po4a is all perl so this does not work. See my words below the Code "... but pearl is not my language." :-) The Code was just a hint, I understand. All I was saying is that po4a does not just call the 'gettext' command line utility. It links to the Locale::gettext perl module and then calls its gettext() and dgettext() functions. So it's not as simple as just wrapping the gettext tool in a script. And, the gettext.pm perl module does not use the command line utility either. Instead it directly links with libgettext.so and won't load if it's missing. So we basically have four solutions: 1) rip out all references to '.*gettext.*' from po4a. But this will result in a big diff which will make it hard to merge with later versions. 2) modify po4a to abstract all calls to gettext. This will also result in a big diff but might possibly be accepted upstream. 3) write a fake Locale::gettext perl module and force po4a to use it by hacking PO4AENV. Plus more hacks so users who have a real gettext.pm module can use it and get errors in their own language. 4) accept that Locale::gettext.pm is a requisite to running po4a and instruct users to install it. But I have completed an analysis of the Wine documentation dependencies and I think that solutions 1-3 above are moot as they solve only a tiny bit of the problem. Here's the dependency list: * docbook2html / db2html & co (command line tools) Needed to generate Html, Pdf, etc. Provided by docbook-utils on Debian, Fedora Core and SUSE. * Locale::gettext (perl module) Needed by po4a for localization. Provided by liblocale-gettext-perl on Debian, perl-Locale-gettext on Mandrake, perl-gettext on SUSE. * Text::WrapI18N (perl module) Needed by po4a, probably to wrap the text to put it into the po file and to generate the sgml file. Pure perl (so easy to check in) but depends on Text::CharWidth which is not pure perl. This one was not used in po4a 0.16.2 but I suspect this caused trouble with multibyte locales. Provided by libtext-wrapi18n-perl on Debian. Not found on SUSE. * Term::ReadKey (perl module) Needed by po4a. Not sure why. Provided by libterm-readkey-perl on Debian, perl-Term-ReadKey on Mandrake, perl-TermReadKey on SUSE. * SGMLS Needed by po4a to interface with the nsgmls parser. Pure perl (so easy to check in). Provided by libsgmls-perl on Debian, perl-SGMLS on SUSE. * nsgmls (command line tool) Needed by po4a to parse the Sgml files. Provided by sp on Debian, opensp on SUSE. So there's really no point to focus on Locale::gettext.pm. Also we cannot remove all these dependencies without breaking po4a completely. Finally we could check in all of those. But, except for the pure perl modules, these require a C compiler, which means headers and libraries to link with... We'd be adding more dependencies than we remove. So I think the best is to check for those in the configure script and inform the user of missing dependencies. I attached a patch that does that for illustration purposes. -- Francois Gouget [EMAIL PROTECTED] Index: configure.ac === RCS file: /cvsroot/wine/docs/configure.ac,v retrieving revision 1.2 diff -u -p -r1.2 configure.ac --- configure.ac18 May 2005 19:31:03 - 1.2 +++ configure.ac24 May 2005 17:38:21 - @@ -13,6 +13,13 @@ AC_CHECK_PROGS(DB2PDF, docbook2pdf db2pd AC_CHECK_PROGS(DB2PS, docbook2ps db2ps, false) AC_CHECK_PROGS(DB2TXT, docbook2txt db2txt, false) +dnl Check for the Perl modules and tools needed by po4a +perl -e 'use Locale::gettext; exit 0' 2>/dev/null && wd_perl_gettext="ok" +perl -e 'use Text::WrapI18N; exit 0' 2>/dev/null && wd_perl_wrapi18n="ok" +perl -e 'use Term::ReadKey; exit 0' 2>/dev/null && wd_perl_readkey="ok" +perl -e 'use SGMLS; exit 0' 2>/dev/null && wd_perl_sgmls="ok" +AC_CHECK_PROGS(NSGMLS, nsgmls, false) + dnl Generate output files MAKE_RULES=Make.rules @@ -27,6 +35,69 @@ fr/Makefile AC_OUTPUT + +if test "$DB2HTML" = "false" +then + echo + echo "*** Note: Your system appears to be missing docbook2html and db2html" + echo "*** which is needed to convert the documentation to HTML." + echo "*** To remedy this you will need one of the following packages" + echo "*** - Debian:docbook-utils" + echo "*** - Fedora Core: docbook-utils" + echo "*** - SUSE: docbook-utils" +fi + +if test "x$wd_perl_gettext" = "x" +then + echo + echo "*** Note: Your system appears to be missing the Locale::gettext perl module" + echo "*** which is needed to build the translated documentation using po4a." + echo "*** To remedy this you wi
Release notes
Hi guys, Raphael pointed out on IRC that the great OpenGL work that went into the last release wasn't mentioned in the "What's new" list that goes out with each snapshot. As it's unreasonable to expect Alexandre to remember or mention every large piece of work that goes into any given release, how about we use the Wiki to note big items as they are checked into CVS. By "big item" I mean either: - Large improvements to a particular subsystem - Adding "gold" compatibility with a well known app - Some other end-user interesting feature For instance, I'd say "header cleanups" are less interesting to users than "OpenGL improvements for Warcraft". That's not a criticism of Alexandre, it's totally reasonable that he puts things in that he can quickly remember and as he's closer to parts of the system like import libraries and headers it's natural that this is what springs to mind first. But we can do better. If people think it's a good idea, I'll create a scratchpad page on the Wiki we can use for the next release. Anybody should be able to add things that are "big", then when doing a release Alexandre can pick and choose the ones he thinks are best to put in What's New. Thoughts? thanks -mike
Re: [dbghelp] dwarf2 support progress step 5
On Tuesday 24 May 2005 12:15, Alexandre Julliard wrote:
> Raphael <[EMAIL PROTECTED]> writes:
> > Hi,
> >
> > This times symt model construction seems good :)
> >
> > But for debug lines, i don't really understand the sm/regs concept :(
> >
> > Changelog:
> > - implement dwarf2_find_symt_by_ref and dwarf2_add_symt_ref using
> > hashtables - some debug lines defines
> > - handle forwards references (ie dwarf2_find_symt_by_ref returns NULL)
> > using ref hashtable
> > - better traces
>
> It doesn't compile, you probably forgot part of the diff:
>
> elf_module.c: In function `elf_load_debug_info_from_map':
> elf_module.c:901: too few arguments to function `dwarf2_parse'
> make: *** [elf_module.o] Error 1
Oooops you are right (taking a brown paper bag)
attached missing part
Thx
Regards,
Raphael
Index: elf_module.c
===
RCS file: /home/wine/wine/dlls/dbghelp/elf_module.c,v
retrieving revision 1.21
diff -u -r1.21 elf_module.c
--- elf_module.c 17 May 2005 14:32:55 - 1.21
+++ elf_module.c 24 May 2005 22:01:41 -
@@ -886,23 +886,27 @@
const char* dw2_debug;
const char* dw2_debug_abbrev;
const char* dw2_debug_str;
+const char* dw2_debug_line;
FIXME("Alpha-support for Dwarf2 information for %s\n", module->module.ModuleName);
dw2_debug = elf_map_section(fmap, debug_sect);
dw2_debug_abbrev = elf_map_section(fmap, debug_abbrev_sect);
dw2_debug_str = elf_map_section(fmap, debug_str_sect);
-if (dw2_debug != NO_MAP && NO_MAP != dw2_debug_abbrev && dw2_debug_str != NO_MAP)
+dw2_debug_line = elf_map_section(fmap, debug_line_sect);
+if (dw2_debug != NO_MAP && NO_MAP != dw2_debug_abbrev && dw2_debug_str != NO_MAP && dw2_debug_line != NO_MAP)
{
/* OK, now just parse dwarf2 debug infos. */
ret = dwarf2_parse(module, module->elf_info->elf_addr,
dw2_debug, fmap->sect[debug_sect].shdr.sh_size,
dw2_debug_abbrev, fmap->sect[debug_abbrev_sect].shdr.sh_size,
- dw2_debug_str, fmap->sect[debug_str_sect].shdr.sh_size);
+ dw2_debug_str, fmap->sect[debug_str_sect].shdr.sh_size,
+ dw2_debug_line,fmap->sect[debug_line_sect].shdr.sh_size);
}
elf_unmap_section(fmap, debug_sect);
elf_unmap_section(fmap, debug_abbrev_sect);
elf_unmap_section(fmap, debug_str_sect);
+elf_unmap_section(fmap, debug_line_sect);
if (!ret)
{
WARN("Couldn't correctly read stabs\n");
pgp3VfPsSTxto.pgp
Description: PGP signature
Re: Write problem with MS Office 2003
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Checking against This->pidlRoot makes writing work. > Is the attached patch correct? That appears as if it would work. Although I must say my curiosity isn't quite satisfied. There's the comment in shlfldr_fs.c about dwAttributes, saying it should be used. And yet it's never initialized. So it seems to me you could remove dwAttributes and the bad comment next to it, or you could: - initialize it in Initialize and InitializeEx, using SHELL32_GetItemAttributes with This->pidlRoot - use This->dwAttributes in fnGetAttributesOf when cidl == 0 The latter way would be more performant perhaps. Also, whichever method you choose, please make sure to make the same change in the remaining implementations of IShellFolder. Thanks, --Juan __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Re: Wine on Sparc
Chuck Hall wrote: Guess that means I need to learn autoconf and related stuff. I just want to make sure you understood that when Eric Frias wrote: ... Winelib only, of course, none of the emulation stuff is going to work on Sparc. What that means is that you won't be able to run Windows programs on your Sparc, unless of course you have the source code and recompile them. As long as you do realize that, then have fun...
Re: Compiling with winelib
On Tue, 24 May 2005 [EMAIL PROTECTED] wrote: > Hello, > > Im trying to compile with winelib the notepad following the steps in the > user guide. > When I run the make command, the compiler gives me errors with the .rc > files. > Then I try to compile without these files and the compiler gives me the > next error: > > bash-2.03$ make > gcc -c -I. -I/usr/local/include/wine/windows -g -O2 -fPIC-D_REENTRANT > -o dialog.o dialog.c > LD_LIBRARY_PATH=":$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -o > notepad2.exe.spec.c --exe notepad2.exe -mgui License_En.o dialog.o > license.o main.o notepad.exe.dbg.o -L/usr/local/lib -L/usr/local/lib/wine > -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 > -lshell32 -luser32 -lwinspool > gcc -c -I. -I/usr/local/include/wine/windows -g -O2 -fPIC-D_REENTRANT > -o notepad2.exe.spec.o notepad2.exe.spec.c > gcc -shared -Wl,-Bsymbolic -o notepad2.exe.so License_En.o dialog.o > license.o main.o notepad.exe.dbg.o notepad2.exe.spec.o-lwine > -lwine_unicode -lwine_uuid -lsocket -lw -lm > dialog.o: In function `DIALOG_FilePrint': > /opt/cfw/wine/programs/notepad2/dialog.c:380: undefined reference to > `strcpy' > /opt/cfw/wine/programs/notepad2/dialog.c:381: undefined reference to > `strlen' > dialog.o: In function `DIALOG_SelectFont': > /opt/cfw/wine/programs/notepad2/dialog.c:675: undefined reference to > `memcpy' > /opt/cfw/wine/programs/notepad2/dialog.c:688: undefined reference to > `memcpy' > dialog.o: In function `DIALOG_Search': > /opt/cfw/wine/programs/notepad2/dialog.c:697: undefined reference to > `memset' > main.o: In function `NOTEPAD_InitData': > /opt/cfw/wine/programs/notepad2/main.c:100: undefined reference to `strlen' > /opt/cfw/wine/programs/notepad2/main.c:102: undefined reference to `strlen' > /opt/cfw/wine/programs/notepad2/main.c:104: undefined reference to `strlen' > /opt/cfw/wine/programs/notepad2/main.c:106: undefined reference to `strlen' > main.o: In function `HandleCommandLine': > /opt/cfw/wine/programs/notepad2/main.c:205: undefined reference to `printf' > /opt/cfw/wine/programs/notepad2/main.c:221: undefined reference to `strlen' > /opt/cfw/wine/programs/notepad2/main.c:231: undefined reference to `strlen' > /opt/cfw/wine/programs/notepad2/main.c:231: undefined reference to `strcmp' > /opt/cfw/wine/programs/notepad2/main.c:238: undefined reference to > `strncpy' > /opt/cfw/wine/programs/notepad2/main.c:239: undefined reference to `strcat' > main.o: In function `WinMain': > /opt/cfw/wine/programs/notepad2/main.c:276: undefined reference to `memset' > test -f notepad2 || install wineapploader notepad2 > find: no es posible abrir notepad2: No existe tal archivo o directorio > find: no es posible seguir enlace simbólico /etc/wtmpx: No existe tal > archivo o directorio > install: wineapploader was not found anywhere! > make: *** [notepad2.exe.so] Error 2 > > > This error appears because I have not the include line. Wont > winelib must link with this file when I compile? > Im using this version of Wine: Wine-20030618.tar.gzin a Solaris 8 > (SPARC) > How can I know if winelib is correctly installed? Did you install the development libaries when Solaris was installed? If you did not that would explain why you are not linking string.h. One other thing that might help is to try using the current release or CVS. Based on the date of the wine you are attempting to use, it has been almost 2 years, many changes have been done in that time. Winelib will not be installed if the make failed. -- Have Fun! Chuck Hall
Re: Wine on Sparc
On Mon, 23 May 2005, Eric Frias wrote: > Chuck Hall wrote: > > I should have mentioned what tools I'm using and the why I sent the patch. > > I am using the native Sun assembler and linker. The Sun assembler does > > not understand the .previous so that is the reason for the patch. > > Makes sense. If you get the Sun assembler to work, we should probably > make an autoconf test to check which assembler gcc is using. Heck, if > you find that Sun's assembler doesn't work, it would be nice to have an > autoconf check to put up an error. I don't know of a good way to do > this check (aside from testing whether it understands .previous). Guess that means I need to learn autoconf and related stuff. > > Using the binutils from www.blastwave.org I managed to get only the first > > 5 files of 'make depend' to compile before it had problems with assembler. > > Seems to be easier to use the native version. > > Wine's README says: > === > Solaris info: >You will most likely need to build Wine with the GNU toolchain >(gcc, gas, etc.). Warning : installing gas does *not* ensure that it >will be used by gcc. Recompiling gcc after installing gas or >symlinking cc, as and ld to the gnu tools is said to be necessary. > === > If you want to compile with the native assembler, you may be in > uncharted territory. I've had success with the combination of > binutils-2.14 and gcc-3.4.2. When was the last time the Wine README was updated? Using the GNU toolchain I get a few more warning messages during 'make depend' but it does work. Gcc, gas, and gld need to be from the GNU toolchain, the rest seems to work as Solaris native. You mentioned that you had patches for Wine on SPARC, would you mind sharing them or should I do a google search for them? -- Have Fun! Chuck Hall
Re: Bugzilla wiki
On Tue, 2005-05-24 at 12:37 -0500, Dustin Navea wrote: > Alexandre, Jeremy, is there any chance that a link to the bugzilla wiki > could be put into the sidebars for the winehq main page and the bugzilla > main page? That way people can read that, as it has some preferred > guidelines on posting (including initial bug reports). If we can get a > link there, or at least in the docs, it should cut down on some of the > dupes I have been getting, and also make it easier to diagnose bugs. I don't think a link is the main site sidebar right place for that. A link in the Bugzilla sidebar works for me though. One could also edit the intro text on the Bugzilla page with a link. I'll go ahead and edit the Bugzilla sidebar.
Re: Write problem with MS Office 2003
On Tuesday 24 May 2005 22:45, Stefan Dösinger wrote: > Is the attached patch correct? I am not sure because I don't know much > about these things, so I am not submitting it to wine-patches yet. > Any suggestions? Just realized that there's still a problem with your patch. At the moment, you are querying the attributes of the drive. You probably have to bind to the folder's parent with SHBindToParent. Then call SHELL32_GetItemAttributes on the parent, with the last element of the original pidl (which SHBindToParent provides for you). Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Write problem with MS Office 2003
On Tuesday 24 May 2005 22:45, Stefan Dösinger wrote: > On an write-protected > folder, this check still succeeds(the read-only flag is removed). This is from ntdll/directory, line 792: if (!(st.st_mode & (S_IWUSR | S_IWGRP | S_IWOTH))) info->FileAttributes |= FILE_ATTRIBUTE_READONLY; So the readonly flag is set only if nobody (not even the file owner or members of the file owner's group) have read privileges. So it's not a problem in the shell folders, it's a problem in ntdll. I wonder if this is correctly implemented. Should'nt we check if the current user has read privileges? Or is this the behaviour that windows shows on an ntfs filesystem? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Help with winelib and development
Am Dienstag, 24. Mai 2005 16:57 schrieb Afkhampour, Cyrus: > Hi I am trying to learn how to use winelib/wine as I am trying to port a > piece of code from windows to Linux and was told that wine might be the > tool to use. I have downloaded wine and begna the winelib tutorial but > now I can not find the winemaker file to save my life. Can someone > explain what I am missing? winemaker is a shell script which should have been installed in your patch when you did 'make install'. Try executing 'winemaker .' in your code directory(make a backup first). This did the trick when I made experiments with small MSVC++ apps. If winemaker is not there there's something wrong with your wine setup Stefan
Re: Write problem with MS Office 2003
Am Dienstag, 24. Mai 2005 17:10 schrieb Juan Lang:
> Hi Stefan,
>
> --- Stefan Dösiner <[EMAIL PROTECTED]> wrote:
> > How do I handle apidl == NULL? As far as I understand, apidl specifies a
> > list
> > of folders/files to be checked, right? If apidl == 0, what folder should
> > I
> > check. Is there some 'current folder' in the IShellFolder class? I
> > didn't
> > find any.
>
> Right, apidl can't be NULL if cidl is nonzero. If cidl is zero, you
> probably need the check to be in the caller. E.g. in shfldr_fs.c, the
> current folder is what calls SHELL32_GetItemAttributes, from
> IShellFolder_fnGetAttributesOf. Perhaps the dwAttributes member that's
> passed to InitializeEx sets the correct attributes for the current folder?
> I'm not sure.
This->pidlRoot looks promissing
Checking against This->pidlRoot makes writing work. On an write-protected
folder, this check still succeeds(the read-only flag is removed). Perhaps a
test with windows is needed. If I try to write to an write-protected folder
in win2k, Windows simply ingores the write protection. Under Wine there's an
error later on if the file can't be written to.
Is the attached patch correct? I am not sure because I don't know much about
these things, so I am not submitting it to wine-patches yet.
Any suggestions?
Stefan
Index: dlls/shell32/shfldr_fs.c
===
RCS file: /home/wine/wine/dlls/shell32/shfldr_fs.c,v
retrieving revision 1.39
diff -u -r1.39 shfldr_fs.c
--- dlls/shell32/shfldr_fs.c 10 May 2005 08:28:11 - 1.39
+++ dlls/shell32/shfldr_fs.c 24 May 2005 18:43:22 -
@@ -575,7 +575,7 @@
_ICOM_THIS_From_IShellFolder2 (IGenericSFImpl, iface)
HRESULT hr = S_OK;
-
+
TRACE ("(%p)->(cidl=%d apidl=%p mask=%p (0x%08lx))\n", This, cidl, apidl,
rgfInOut, rgfInOut ? *rgfInOut : 0);
@@ -587,11 +587,16 @@
if (*rgfInOut == 0)
*rgfInOut = ~0;
-while (cidl > 0 && *apidl) {
-pdump (*apidl);
-SHELL32_GetItemAttributes (_IShellFolder_ (This), *apidl, rgfInOut);
-apidl++;
-cidl--;
+if(cidl == 0)
+SHELL32_GetItemAttributes (_IShellFolder_ (This), This->pidlRoot, rgfInOut);
+else
+{
+while (cidl > 0 && *apidl) {
+pdump (*apidl);
+SHELL32_GetItemAttributes (_IShellFolder_ (This), *apidl, rgfInOut);
+apidl++;
+cidl--;
+}
}
/* make sure SFGAO_VALIDATE is cleared, some apps depend on that */
*rgfInOut &= ~SFGAO_VALIDATE;
Help with winelib and development
Title: Help with winelib and development Hi I am trying to learn how to use winelib/wine as I am trying to port a piece of code from windows to Linux and was told that wine might be the tool to use. I have downloaded wine and begna the winelib tutorial but now I can not find the winemaker file to save my life. Can someone explain what I am missing?
Re: ITSS Conformance Test Patch
Dimi Paun wrote: From: "Chris Watmore" <[EMAIL PROTECTED]> This patch adds tests for the itss dll. Please no Perl or Shell scripts -- they will not run on Windows, where we ship tests via winetest. Just code them in C, it shouldn't be too hard. The scripts Chris submitted are used for generating the source files for the test, not for running them. Rob
Re: ITSS Conformance Test Patch
From: "Chris Watmore" <[EMAIL PROTECTED]> > This patch adds tests for the itss dll. Please no Perl or Shell scripts -- they will not run on Windows, where we ship tests via winetest. Just code them in C, it shouldn't be too hard. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Bugzilla wiki
Hey everyone, I've just finished the bugzilla wiki.. If anyone has any comments or changes, go ahead and post them. Alexandre, Jeremy, is there any chance that a link to the bugzilla wiki could be put into the sidebars for the winehq main page and the bugzilla main page? That way people can read that, as it has some preferred guidelines on posting (including initial bug reports). If we can get a link there, or at least in the docs, it should cut down on some of the dupes I have been getting, and also make it easier to diagnose bugs. Todo: * find out _every_ valid flag that can be passed to wine via the WINEDEBUG= variable * post them into a separate wiki * post a link from the bugzilla wiki to that new wiki If anyone wants to start emailing me flags and what they do or can be useful for tracing, feel free, and I will get the wiki page started either tonight or tomorrow. Dustin
Re: Write problem with MS Office 2003
Hi Stefan, --- Stefan Dösiner <[EMAIL PROTECTED]> wrote: > How do I handle apidl == NULL? As far as I understand, apidl specifies a > list > of folders/files to be checked, right? If apidl == 0, what folder should > I > check. Is there some 'current folder' in the IShellFolder class? I > didn't > find any. Right, apidl can't be NULL if cidl is nonzero. If cidl is zero, you probably need the check to be in the caller. E.g. in shfldr_fs.c, the current folder is what calls SHELL32_GetItemAttributes, from IShellFolder_fnGetAttributesOf. Perhaps the dwAttributes member that's passed to InitializeEx sets the correct attributes for the current folder? I'm not sure. --Juan __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Re: question about standalone tests
On Tue, May 24, 2005 at 05:24:11PM +0200, Alexandre Julliard wrote: > You should be able to build by simply copying over wine/test.h, it's > supposed to compile with MSVC too. If it doesn't this should be > fixed. There's no reason to add special magic in every test file for > that. Okay, cool. That should probably be noted somewhere in the FAQ. Also, perhaps the lz tests should be updated as well, since they are regularly mentioned as the basic example developers should work from. -- Kees Cook@outflux.net
Re: UT2003 Regression - Patch at last :-))
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes: > What about instead of the send_ncpaind/send_erase when child==prev (assuming > this to be the more 'unusual' case and not the norm) I build a list of the > hwnds and validate their update region. When the loop completes, for each > hwnd left in the list I do the send_ncpaint/send_erase processing? > > Without removing the update region there's no way to step further in the > list, if I understand the problem correctly? Yes, but that's what needs to be fixed, we need to make progress even if the update region is not validated. We will then get a WM_PAINT in the main message loop, which I believe is what we want. -- Alexandre Julliard [EMAIL PROTECTED]
Re: question about standalone tests
Kees Cook <[EMAIL PROTECTED]> writes: > Hi! My crypt32 protectdata tests were just added to CVS (thanks!) but > they were added without the #ifndef STANDALONE stuff that exists in the > recommended example from the lzexpand test code. The steps here: > http://www.winehq.com/site/docs/wine-devel/testing-windows > don't have a method for doing the build with the free-of-charge windows > CLI compiler (which the "STANDALONE" stuff works fine with). You should be able to build by simply copying over wine/test.h, it's supposed to compile with MSVC too. If it doesn't this should be fixed. There's no reason to add special magic in every test file for that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: question about standalone tests
From: "Kees Cook" <[EMAIL PROTECTED]> > Is there some new way to build standalone tests, or should I send a > patch for re-including the #ifndef STANDALONE stuff for the tests? Please don't add the ugly #idfes back. What you need is an out-of-source (dummy) implementation of the Wine test framework that would allow the tests to build unmodified. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
question about standalone tests
Hi! My crypt32 protectdata tests were just added to CVS (thanks!) but they were added without the #ifndef STANDALONE stuff that exists in the recommended example from the lzexpand test code. The steps here: http://www.winehq.com/site/docs/wine-devel/testing-windows don't have a method for doing the build with the free-of-charge windows CLI compiler (which the "STANDALONE" stuff works fine with). Is there some new way to build standalone tests, or should I send a patch for re-including the #ifndef STANDALONE stuff for the tests? -- Kees Cook@outflux.net
PowerPaint not working
I installed PowerPaint (free on thw Net, somewhere) OK, but when I try
to run it I get a message box telling me the installation is corrupt,
and the following output from Wine.
[EMAIL PROTECTED]:~/.wine/drive_c/Program Files/FLISoft/PowerPaint> wine
PowerPaint.exe
fixme:shell:SHGetFileInfoW set icon to shell size, stub
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:CoCreateInstance no classfactory created for CLSID
{47ad7e45-ba98-47e4-887f-9ab7a07f7d4d}, hres is 0x80040150
fixme:ole:CoRegisterMessageFilter stub
I am using the latest CVS of Wine.
--
Andrew
You can be the captain
I will draw the chart
Sailing into destiny
Closer to the heart
Closer to the Heart by Rush (A Farewell to Kings, 1977)
~
RE: Bug 2660
>the resulting patch that was attached to the bug do fix the problem. I'm >not sure if the patch has been committed to CVS, but if it hasn't it >probably should before the next wine release... No it hasn't. The problem is that the fix does indeed solve the problem, but also makes the behaviour slightly incorrect. See the latest here... http://www.winehq.org/hypermail/wine-devel/2005/05/0797.html Jason
Compiling with winelib
Hello, Im trying to compile with winelib the notepad following the steps in the user guide. When I run the make command, the compiler gives me errors with the .rc files. Then I try to compile without these files and the compiler gives me the next error: bash-2.03$ make gcc -c -I. -I/usr/local/include/wine/windows -g -O2 -fPIC-D_REENTRANT -o dialog.o dialog.c LD_LIBRARY_PATH=":$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -o notepad2.exe.spec.c --exe notepad2.exe -mgui License_En.o dialog.o license.o main.o notepad.exe.dbg.o -L/usr/local/lib -L/usr/local/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool gcc -c -I. -I/usr/local/include/wine/windows -g -O2 -fPIC-D_REENTRANT -o notepad2.exe.spec.o notepad2.exe.spec.c gcc -shared -Wl,-Bsymbolic -o notepad2.exe.so License_En.o dialog.o license.o main.o notepad.exe.dbg.o notepad2.exe.spec.o-lwine -lwine_unicode -lwine_uuid -lsocket -lw -lm dialog.o: In function `DIALOG_FilePrint': /opt/cfw/wine/programs/notepad2/dialog.c:380: undefined reference to `strcpy' /opt/cfw/wine/programs/notepad2/dialog.c:381: undefined reference to `strlen' dialog.o: In function `DIALOG_SelectFont': /opt/cfw/wine/programs/notepad2/dialog.c:675: undefined reference to `memcpy' /opt/cfw/wine/programs/notepad2/dialog.c:688: undefined reference to `memcpy' dialog.o: In function `DIALOG_Search': /opt/cfw/wine/programs/notepad2/dialog.c:697: undefined reference to `memset' main.o: In function `NOTEPAD_InitData': /opt/cfw/wine/programs/notepad2/main.c:100: undefined reference to `strlen' /opt/cfw/wine/programs/notepad2/main.c:102: undefined reference to `strlen' /opt/cfw/wine/programs/notepad2/main.c:104: undefined reference to `strlen' /opt/cfw/wine/programs/notepad2/main.c:106: undefined reference to `strlen' main.o: In function `HandleCommandLine': /opt/cfw/wine/programs/notepad2/main.c:205: undefined reference to `printf' /opt/cfw/wine/programs/notepad2/main.c:221: undefined reference to `strlen' /opt/cfw/wine/programs/notepad2/main.c:231: undefined reference to `strlen' /opt/cfw/wine/programs/notepad2/main.c:231: undefined reference to `strcmp' /opt/cfw/wine/programs/notepad2/main.c:238: undefined reference to `strncpy' /opt/cfw/wine/programs/notepad2/main.c:239: undefined reference to `strcat' main.o: In function `WinMain': /opt/cfw/wine/programs/notepad2/main.c:276: undefined reference to `memset' test -f notepad2 || install wineapploader notepad2 find: no es posible abrir notepad2: No existe tal archivo o directorio find: no es posible seguir enlace simbólico /etc/wtmpx: No existe tal archivo o directorio install: wineapploader was not found anywhere! make: *** [notepad2.exe.so] Error 2 This error appears because I have not the include line. Wont winelib must link with this file when I compile? Im using this version of Wine: Wine-20030618.tar.gzin a Solaris 8 (SPARC) How can I know if winelib is correctly installed? Thank you. Antonio Fernández.
Re: Bug 2660
Yes this seems to relate to the issue I was having with one of my Delphi apps under wine. I had some fancy degraded frames I had added to Tpanel and this sent recent wine into a infinite redraw situation. I just modded the source for now and am running it under wine-20041019-r3 I _think_ that it may have worked anyway under that version but I dont have time to regression test it all now. It seems the issue is being tackled so this may not be necessary anyway. The rest of the app works almost flawlessly under wine which is great but I have a font problem in some dialogues where I had coded an 8pt that was std on windows but appears not to be in my wine installation. I will have to track it down. Once this patch works its way into a wine release I will test the non-linux version of my software to see if it solves the redraw issue. regards. On Tue, 24 May 2005 08:30:32 +0200, Dustin Navea <[EMAIL PROTECTED]> wrote: This is more directed toward Jason, but I figure everyone should see it. As comments 9-11 note in this bug, the notes mentioned in http://www.winehq.org/hypermail/wine-devel/2005/05/0420.html and the resulting patch that was attached to the bug do fix the problem. I'm not sure if the patch has been committed to CVS, but if it hasn't it probably should before the next wine release... If it has, please post a note to the bug and I will resolve it, referencing to get the next wine release when it comes out, or CVS if someone can't wait.. Dustin -- Using Opera e-mail on Gentoo Linux
Re: Corrected the determination of capturing inside EDIT_WM_MouseMove function.
2005-05-24 Kouji Sasaki <[EMAIL PROTECTED]> (B (B> > Hence, the modification was made so that the text selection by mouse (B> movement will only occur when edit control itself sets the capture. (B> (B> OK, I'm sold, but can you please resubmit the patch with (B> an appropriate comment explaining the problem? (B (BOK. (BI will send the modified patch to wine-patches. (B (B-- (BJustsystem Corporation <[EMAIL PROTECTED]>
RE: qcap/avicap and driver models
Eric Pouch wrote: I've been on vacation for a few days but want to comment on this. > > for it, as rolf kalbermatter pointed out in > > http://www.winehq.com/?issue=274#Video%20Capture%20in%20Windows > > as already stated, drivers should be written as follows: > 1/ since it's wine specific, its name should start with wine > (so winevfw or whatever) We agree here all I think. The postfix may be an issue but the rest is very clear. The idea to try to create one driver for all possible APIs looks like a good one, at least if Alexandre doesn't feel bad about to many conditional compilation macros to support the different possible APIs (if any, I'm only a little bit familiar with v4l) > 2/ the driver shall be a driver for both avicap and qcap DLL As far as I can see it, this is also exactly as Windows does it. The VfWCaptureFilter really is just a DirectShow wrapper around the same installable driver interface as is used in avicap. > 3/ interfaces to the driver should be the regular windows' > ones (fetch information on avicap driver interface, as well as DShow > driver interface - DDK info on the Web are your friend) Apparently there is indeed also a direct interface to WDM stream drivers somewhere, if you mean this with the DirectShow driver interface. However this has no importance for Wine as WDM drivers really are kernel mode drivers and therefore won't be possible to implement nor run in Wine at all. >From what I got from MSDN it appears that the DirectShow drivers implement in kernel space a similar model as is available in user space through the DirectShow filters. The advantage of this is that data can be streamed between DirectShow drivers directly in kernel space through shared memory or similar resources to avoid context switches when transporting data between a capture device, a hardware mixer and a recording device. VFWCaptureFilter is only a legacy interface to allow access to old style vfw drivers from DirectShow applications and only allows access to modern DirectShow drivers through the earlier mentioned vfwwdm32.dll installable driver and translation layer. As such it seems like a big detour to access WDM stream drivers through it but it seems to be what many applications including MSN Messenger are doing anyhow. How Windows avoids double entries of WDM drivers in resource enumeration (one for the translation of the WDM driver through wfwwdm32.dll into a vfw device and one for the direct WDM driver) I haven't looked at nor when exactly the applicable entry in the system registry for a new vfw device based on the WDM driver model is created. Possibly this might be explicitedly part of the installation of a video capture device, an implicit part of some setupapi function when installing a video capture class device, or even implicitedly created by PnP whenever a PnP video device is detected. > Item 4/ has the following benefits: > - it's up to the driver, at runtime, to find out and setup > the existing physical devices > - you don't need to have fancy settings (configuration...), > which most users won't understand Installable drivers support registering and unregistering (here called install and uninstall) as well as an optional configuration message dialog if necessary. While it seem not used in most examples I have seen nor in the wine audio drivers, it might actually be used here in wine to have the driver detect and add the necessary entries to the registry at some time during setup of wine. Maybe through winecfg or directly in the installation script? Rolf Kalbermatter
Re: [dbghelp] dwarf2 support progress step 5
> > > > Changelog:> > - implement dwarf2_find_symt_by_ref and dwarf2_add_symt_ref using hashtables> > - some debug lines defines> > - handle forwards references (ie dwarf2_find_symt_by_ref returns NULL) using > > ref hashtable> > - better traces > > It doesn't compile, you probably forgot part of the diff:> > elf_module.c: In function `elf_load_debug_info_from_map':> elf_module.c:901: too few arguments to function `dwarf2_parse'> make: *** [elf_module.o] Error 1I also would like to review in details the patch (especially why we need to change the inner interfaces in types.c and symbol.c) [there are forward declarations in MSC and stabs parsing and we don't need the hack included here] A+
Re: [RESENT] MSVCRT: Lower Error level of _spawnve
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes:
Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes:
>> @@ -448,7 +448,9 @@ const char *fullname = name; int ret = -1;
>>
>> - FIXME(":not translating name %s to locate program\n",fullname); +
>> /* Is this really a WARN? Native msvcrt doesn't seem to translate the
>> argumentsd neither + [EMAIL PROTECTED] 050516
>> */ + WARN(":not translating name %s to locate program\n",fullname);
Alexandre> Yes, native does transformations on the program name, like
Alexandre> looking for .bat, .cmd etc. if there is no extension. That
Alexandre> FIXME should remain until this is fixed properly.
I was seeing the ../.. and such was not translated on both native and
builtin. I'll try to clear up the command.
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: [RESENT] MSVCRT: Lower Error level of _spawnve
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> @@ -448,7 +448,9 @@
>const char *fullname = name;
>int ret = -1;
>
> - FIXME(":not translating name %s to locate program\n",fullname);
> + /* Is this really a WARN? Native msvcrt doesn't seem to translate the
> argumentsd neither
> + [EMAIL PROTECTED] 050516 */
> + WARN(":not translating name %s to locate program\n",fullname);
Yes, native does transformations on the program name, like looking for
.bat, .cmd etc. if there is no extension. That FIXME should remain
until this is fixed properly.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [dbghelp] dwarf2 support progress step 5
Raphael <[EMAIL PROTECTED]> writes: > Hi, > > This times symt model construction seems good :) > > But for debug lines, i don't really understand the sm/regs concept :( > > Changelog: > - implement dwarf2_find_symt_by_ref and dwarf2_add_symt_ref using hashtables > - some debug lines defines > - handle forwards references (ie dwarf2_find_symt_by_ref returns NULL) using > ref hashtable > - better traces It doesn't compile, you probably forgot part of the diff: elf_module.c: In function `elf_load_debug_info_from_map': elf_module.c:901: too few arguments to function `dwarf2_parse' make: *** [elf_module.o] Error 1 -- Alexandre Julliard [EMAIL PROTECTED]
Re: winedump: Print file offset instead of obscure 'prefix' while dumping data
> > > Print file offset instead of obscure 'prefix' while dumping data.> > prefix is used to properly indent the output of the dump, so you do want to keep > > the prefix (this doesn't prevent you from adding the offsets for dumps)> > The offset is going to replace the prefix, not to coexist with it.> Are you objecting to it? yes, you're loosing the identation of the data-dump that prefix provided A+
Re: Resend: Fix ole32:moniker test for NT4
Richard Cohen <[EMAIL PROTECTED]> writes: > Rediffed against HEAD > > Richard Cohen wrote: > > ... and almost certainly Win9x, 2k, XP > > Changelog: > > + IEnum::Clone shouldn't do a Reset. > > + Don't assume the ROT is already empty when testing The tests fail here: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so moniker.c && touch moniker.ok moniker.c:139: Test failed: Number of matches should be equal to 2 not 0 moniker.c:146: Test failed: Number of matches should be equal to 2 not 0 make[3]: *** [moniker.ok] Error 2 -- Alexandre Julliard [EMAIL PROTECTED]
RE: Bug 2660
(Sent from old email account this time, since I haven't registered the new one yet!) >the resulting patch that was attached to the bug do fix the problem. >I'm >not sure if the patch has been committed to CVS, but if it hasn't it >probably should before the next wine release... No it hasn't. The problem is that the fix does indeed solve the problem, but also makes the behaviour slightly incorrect. See the latest here... http://www.winehq.org/hypermail/wine-devel/2005/05/0797.html Jason
Re: [RESEND] commdlg: use shell32's ILGetDisplayName instead of SHGetPathFromIDList
Michael Jung wrote: Hi Alexandre, could you please give a short comment on this one: http://www.winehq.org/hypermail/wine-patches/2005/05/0533.html My guess is switching on the windows version should be avoided. If that's not possible we should try not to use functions that return different things depending on the windows version inside Wine. Perhaps you can use IShellFolder_GetDisplayNameOf() rather than ILGetDisplayName? Mike
Re: XEmbed embeder support in Wine
Mike Hearn wrote: >On Mon, 23 May 2005 21:31:26 +0200, Jacek Caban wrote: > > >>3. Window is displayed and Wine communicates with X11 window >>using XEmbed protocol >> >> > >How does this work if the app wants to embed an X window as a child win32 >window? We no longer map child win32 windows to child X windows since the >WM rewrite so there's nothing to embed into. > >thanks -mike > > The X window is created as a child window of frame's X window (excluding desktop mode the frame has associated X window), but win32 window can be a child window of any window in this frame. In desktop mode it has to be child window of desktop's X window, but it doesn't work yet. The application can get a window that has to be the parent of embedded window from "__wine_x11_embedder_window" property of _XEMBED window (in application I sent as example I forgot to remove getting window from "__wine_x11_whole_window"). Jacek
[RESEND] commdlg: use shell32's ILGetDisplayName instead of SHGetPathFromIDList
Hi Alexandre, could you please give a short comment on this one: http://www.winehq.org/hypermail/wine-patches/2005/05/0533.html Thanks, -- Michael Jung [EMAIL PROTECTED]
