Re: Any advice please... Console input issue
Le 09/11/2012 22:49, Ann and Jason Edmeades a écrit : Hello, I've been looking at a patch which sorts out NUL and CON handling in a part of the command shell, and have stumbled upon a problem I am not sure how to fix because I really dont understand the underlying console handling, and would appreciate someone pointing me in a direction. For simplicity sake I've cut this down to a tiny test program, which works on windows and fails on wine which does the following: Opens the device (\\.\CON) with CreateFile with GENERIC_READ rights (which internally opens a CONIN$ device with the same access rights) Reads from the device with ReadFile - Because its a console device, this drops through to ReadConsoleW, which creates a CONOUT$ and then waits on a keystroke - Once the key is pressed (WCEL_Get) the key is 'inserted' into the input buffer by calling WriteConsoleInputW The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try to open it with GENERIC_WRITE). CreateFile(CONIN$...) will let me open in GENERIC_READ/GENERIC_WRITE mode and the program works on both windows and wine, but if you open CONIN$ GENERIC_READ only then it fails on wine and works on windows, with the same issue. Now on windows, this works... the question is how to make it work on wine... My gut feeling, with nothing backing this at all, is that WCEL_Get should not use WriteConsoleInputW to inject the values into the input buffer, instead making the server call directly, but passing through to the server call something to indicate that it is ok to add the data to the buffer, but I'm fast getting out of my depth! Thanks for any help! I'll file a bug with my analysis and testcase, but would rather fix the thing! Jason from your (partial) explanation, I assume that : - you're using a bare console, ie didn't run your app under wineconsole, but simply as wine foo.exe - if so, does running your app under wineconsole provides the same bad effects ? - another item to test would be to see if writeconsoleinput really enforces the generic_write flag as msdn states but, for a bare handle, we have to convert unix console keystrokes into win32 keycodes, so we need to feed the keycodes into wine server if we really have to enforce generic_write, then we should wrap for TERM_ functions the calls to writeconsoleinput with a helper that reopens the console with the right mode A+
Re: We're in at FOSDEM!
Am 23.10.2012 17:11, schrieb Jeremy White: I'm stoked - we've been approved for a dev room at FOSDEM on Saturday, February 2nd, in Brussels. It is just the one day, but I figure we can find ways to gather on Friday night and/or Sunday as well. I really think this will be a fun change of pace for us. If it doesn't work out, we'll just go camp out in Marcus's back yard instead evil grin. One thing they require from us is a pre set schedule, so I'll be asking people to suggest topics, and then we'll have to weed through them to figure out what makes the most sense. Hi, We should stay in the same hotel if possible to ease gathering. Did someone already choose one? Could You make a special arrangement again (like in Paris, IIRC)? How long is a fosdem day? As of fosdem 2012 archive it seems 10:30-19:00(7pm). I'm asking all that because i plan to travel per train, and it can be much cheaper if you book early. -- Best Regards, André Hentschel
Re: [PATCH] tools/widl/header.c: Add a way to declare interface data members.
On 11/11/2012 03:00 AM, Max TenEyck Woodbury wrote: I mentioned this a few days ago. It would have helped if you had raised this point then. I tried, but your email made no sense. You didn't even mention that you're talking about COM interfaces. As it stands, it is simply a way to adding data members to an aggregate with an interface. In that sense it is not an addition to the interface since the Vtbl pointer remains exactly as before. The new information is not part of the interface as such. Putting it in the same 'struct' as the Vtbl is simply a way of enforcing the association. If you do not define a iface_IFACE_DATA macro, nothing happens. bye michael
Re: [PATCH] tools/widl/header.c: Add a way to declare interface data members.
On 11/11/2012 07:12 AM, Max TenEyck Woodbury wrote: On 11/11/2012 01:01 AM, Nikolay Sivov wrote: On 11/11/2012 05:00, Max TenEyck Woodbury wrote: I mentioned this a few days ago. It would have helped if you had raised this point then. As it stands, it is simply a way to adding data members to an aggregate with an interface. Data members to an aggregate? What are you talking about and what it has to do with interface definition? An aggregate is a collection of information, like a class, struct or union. Your mixing up terminology. Some aggregates include 'interface's, a COM, OLE or RPC thingy. The interface can have only methods defined, but those methods might want access to some additional data. To get to that data, the method now has to build a pointer to the containing aggregate and reference the data through that pointer. This introduces complications to the code since the data may not be in same place in the aggregate in each instance where the interface is used. You need a slightly different code sequence for each different place the method is needed. However, the source code will be virtually identical for each instance. This patch allows those aggregate data members associated with the interface, which are not technically part of the interface, to be placed in a fixed relation to the interfaces Vtbl pointer. (Practically the Vtbl pointer is the interface.) By establishing such a relationship, the need to convert from the pointer to the interface (specifically to its Vtbl pointer) to a pointer to its containing aggregate in order to get to the relevant data is removed. Please check how a C compiler is laying out structs in memory. In both cases the data is at a fixed offset (calculated at compile time) in relation to the interface. Now, technically, the associated data is not part of the interface. It is part of the aggregate containing and implementing the interface. Moving the declaration from the aggregate to the end of the struc for the interface is a hack that lets simpler and more general code to be generated. So, it's a hack, that you only use if you want to, to speed up execution and simplify maintenance. It is a hack that breaks the ABI (sizeof(interface) == sizeof(void*)), doesn't improves the generated code, doesn't simplify maintenance at all, quite the contrary. This sounds more like trolling than a serious attempt to improve Wine. bye michael
Re: [PATCH 1/2] oleaut32/tests: Add test for ITypeInfo2_fnGetContainingTypeLib
Nikolay Sivov wrote 07.11.2012 13:45:
On 11/7/2012 11:36, Tatyana Fokina wrote:
Hi, Tatyana.
Some comments:
dlls/oleaut32/tests/Makefile.in | 1 +
dlls/oleaut32/tests/typelib2.c | 69
+
2 files changed, 70 insertions(+)
create mode 100644 dlls/oleaut32/tests/typelib2.c
You don't need a separate file for this, please use typelib.c
+hr = CreateTypeLib2(SYS_WIN32, jsdeb, (ICreateTypeLib2
**)ctl2);
+if(hr != S_OK)
+{
+skip (CreateTypeLib2 failed\n);
+return;
+}
+
+hr = ICreateTypeLib2_CreateTypeInfo(ctl2, jsname,
TKIND_DISPATCH, cti);
+if(hr != S_OK)
+{
+skip (ICreateTypeLib2_CreateTypeInfo failed\n);
+return;
+}
That's not what skip() is for. Also you leak on second return and you
don't need a cast for ctl2.
+hr = ITypeInfo2_GetContainingTypeLib(ti2, (ITypeLib **)tl,
Index);
+ok(!hr, ITypeInfo2_GetContainingTypeLib failed on Index\n);
+if(!hr)ITypeLib_Release(tl);
Please test return value for S_OK here, again you don't need a cast
here.
+hr = ITypeInfo2_GetContainingTypeLib(ti2, (ITypeLib **)tl,
Index);
+ok(!hr, ITypeInfo2_GetContainingTypeLib failed on Index\n);
+if(!hr)ITypeLib_Release(tl);
+
+hr = ITypeInfo2_GetContainingTypeLib(ti2, (ITypeLib **)tl,
pIndex);
+ok(!hr, ITypeInfo2_GetContainingTypeLib failed on pIndex =
NULL\n);
+if(!hr)ITypeLib_Release(tl);
What are you trying to do with index pointer?
Hi, Nikolay.
Thank you for your response. I fixed it.
Re: [PATCH] tools/widl/header.c: Add a way to declare interface data members.
On 11/11/2012 03:05 PM, Michael Stefaniuc wrote: On 11/11/2012 07:12 AM, Max TenEyck Woodbury wrote: On 11/11/2012 01:01 AM, Nikolay Sivov wrote: On 11/11/2012 05:00, Max TenEyck Woodbury wrote: I mentioned this a few days ago. It would have helped if you had raised this point then. As it stands, it is simply a way to adding data members to an aggregate with an interface. Data members to an aggregate? What are you talking about and what it has to do with interface definition? An aggregate is a collection of information, like a class, struct or union. Your mixing up terminology. Please excuse the confusion. I learned that usage when I worked for DEC in the 1980's. Some aggregates include 'interface's, a COM, OLE or RPC thingy. The interface can have only methods defined, but those methods might want access to some additional data. To get to that data, the method now has to build a pointer to the containing aggregate and reference the data through that pointer. This introduces complications to the code since the data may not be in same place in the aggregate in each instance where the interface is used. You need a slightly different code sequence for each different place the method is needed. However, the source code will be virtually identical for each instance. This patch allows those aggregate data members associated with the interface, which are not technically part of the interface, to be placed in a fixed relation to the interfaces Vtbl pointer. (Practically the Vtbl pointer is the interface.) By establishing such a relationship, the need to convert from the pointer to the interface (specifically to its Vtbl pointer) to a pointer to its containing aggregate in order to get to the relevant data is removed. Please check how a C compiler is laying out structs in memory. In both cases the data is at a fixed offset (calculated at compile time) in relation to the interface. I believe you are confused here. The relative addresses in the original may change if changes are made to the aggregate. If you want to tell the compiler which aggregate member you want to use, you need to use a pointer to the aggregate. It has no way to figure out what you are talking about unless you give it that without this hack. Now, technically, the associated data is not part of the interface. It is part of the aggregate containing and implementing the interface. Moving the declaration from the aggregate to the end of the struc for the interface is a hack that lets simpler and more general code to be generated. So, it's a hack, that you only use if you want to, to speed up execution and simplify maintenance. It is a hack that breaks the ABI (sizeof(interface) == sizeof(void*)), doesn't improves the generated code, doesn't simplify maintenance at all, quite the contrary. This sounds more like trolling than a serious attempt to improve Wine. That depends on exactly what you call the 'interface'. If you call the Vtbl the interface, the size does not change. If you call the 'struct' containing the Vtbl the interface (which someone else pointed out is only an artifact of the implementation technique), it changes. So, as with most hacks, you have to be careful what you ask for. I might change my mind if you point out an existing non-contrived example of using sizeof(interface) that this would break. The real question is ;Could it be useful?'. I think the answer is 'yes'.
Re: [PATCH] includes: always add __force_align_arg_pointer__ for i386
Maarten Lankhorst m.b.lankho...@gmail.com wrote: Fixes flstudio installer on my system, which breaks otherwise in strcasestr_sse42_nonascii due to stack being misaligned. That's a compiler bug: http://bugs.winehq.org/show_bug.cgi?id=22316 -- Dmitry.
Wine and multiarch on Debian Testing
On Wed, 17 Oct 2012, Erich E. Hoover wrote: I just upgraded to 12.04, until they fix the 32-bit headers problem you'll have to manually create the symbolic links for the -dev package behavior: I ran into pretty much the same set of problems with Wine on Debian Testing. However some development packages are already multiarch-compatible so I installed them and created a bit fewer symbolic links than you. In particular I was able to install the following i386 development packages: libasound2-dev:i386 libcapi20-dev:i386 libjpeg8-dev:i386 liblcms1-dev:i386 libldap2-dev:i386 libmpg123-dev:i386 libopenal-dev:i386 libtinfo-dev:i386 (needed for ncurses) libv4l-dev:i386 libx11-dev:i386 libxau-dev:i386 libxcb1-dev:i386 libxinerama-dev:i386 libxml2-dev:i386 libxrender-dev:i386 zlib1g-dev:i386 I also made a list of the packages that need to be fixed in order for work on Wine to be possible without so much complication, and made sure we have bugs to track the status of each of them. I am sure the maintainers would appreciate some help so here are the multiarch fixes needed for Wine development: * These all seem to be fixable trivially. Double-check and submit a patch? The Debian freeze might block your efforts though :-( libfontconfig1-dev - #677885 libgl1-mesa-dev - #678040, #689088 libglu1-mesa-dev - #678040, #689089 libgnutls-dev - #678070 libosmesa6-dev - #678040 libxcomposite-dev - #689082 libxfixes-dev - #677657 libxrandr-dev - #678895 libxvmc1 - #640499 (well the work seems to have been done in any case) libxxf86vm-dev - #678898 * These have yet to be analyzed to figure out if there are obstacles or not. libcups2-dev - #689084 libgphoto2-2-dev - #689083 libgstreamer0.10-dev - #689090 libnss-mdns - #686984 libpng12-dev - #689092, #673642 libsane-dev - #689073, #672495 libxi-dev - #689068 * The freetype-config tool is the point of contention. libfreetype6-dev - #666761 * The point of contention here is xslt-config. This is probably somewhat similar to the freetype-config issue. libxslt1-dev - #689091 * These have platform-dependent headers which makes fixing much harder. Either the headers can be made platform-independent upstream (assuming it even makes sense), or it will have to wait for the build toolchain to be updated: https://wiki.ubuntu.com/MultiarchSpec#Co-installable_-dev_packages libdbus-1-dev - #689071 libncurses5-dev / libncursesw5-dev - #689131, #646761, #646977 libssl-dev - #689093, #638137 libtiff4-dev - #689085 * The maintainer says that any application that still uses HAL is buggy and that he will not fix this package :-( libhal1, libhal1-dev - #638839 * Broken by other packages. See above. libxcursor-dev - broken by libxfixes-dev libgl1-nvidia-glx - broken by libxvmc1 * These are not needed by Wine but I need them to compile other stuff so I'm including them here. For most of these the GObject introspection data causes trouble. libatk1.0-dev - #689124 (to be checked) libcairo2-dev - #689122 (to be checked) libgdk-pixbuf2.0-dev - #689125 (introspection) libglib2.0-dev - #683593 (likely introspection) libgtk2.0-dev - #689097 (introspection) libpango1.0-dev - #683592 (trivial) Here are some references for anyone not yet familiar with multiarch on Debian: * Multiarch HOWTO for users http://wiki.debian.org/Multiarch/HOWTO * Multiarch package manager specification https://wiki.ubuntu.com/MultiarchSpec * All the links http://wiki.debian.org/Multiarch -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
Question on debugging wineboot..
What is the proper way to debug wineboot and services.exe in order to find out
what is causing the error outputted by wineserver below?
err:wineboot:start_services_process Couldn't start services.exe: error 1359
wine: failed to update /winearm/winehome with
/winearm/bin/../share/wine/wine.inf: No such file or directory
My problem is that doing:
gdb /winearm/bin/wine C:\\windows\\system32\\wineboot.exe --init
will yield the code flow to start_wineboot() again because
peb-ProcessParameters-ImagePathName.Buffer is NULL
if (peb-ProcessParameters-ImagePathName.Buffer)
{
strcpyW( main_exe_name, peb-ProcessParameters-ImagePathName.Buffer );
}
else
{
deleted code
start_wineboot( boot_events );
}
So it looks like running GDB on wineboot by itself is not good enough because
something from the original process is missing, causing it to think it needs to
start wineboot again. The reason I had to start it under its own GDB process
is because the original GDB process will not follow the fork() in
start_wineboot.
How do you guys debug all the processes being fork'ed off when GDB can't follow
to the child process?
Thanks in advance
Roger R. Cruz
