I am a delphi developer (not limited to this language, I have done several projects in C, C#, as well as assembly but for the purposes of this email I am a delphi developer). I am experiencing some weirdness in regards to the richedit control in regards to database access (Specifically TDBRichEdit), Since I am a delphi developer using wine this means I have access to A) My programs source code, B) Delphis VCL source code (So i can view how delphi manages the richedit control which in this case is split up among 3 files) and C) The Wine source code. I have two questions 1) Since Delphi does not actually implement any of richedits features, merely wraps around them I should be in the clear to create a patch to wine to correct this functionality correct? and 2) What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).
On 1/19/07, Jacob Alberty jacob.alberty@vetmanage.com wrote:
I am a delphi developer (not limited to this language, I have done several projects in C, C#, as well as assembly but for the purposes of this email I am a delphi developer). I am experiencing some weirdness in regards to the richedit control in regards to database access (Specifically TDBRichEdit), Since I am a delphi developer using wine this means I have access to A) My programs source code, B) Delphis VCL source code (So i can view how delphi manages the richedit control which in this case is split up among 3 files) and C) The Wine source code. I have two questions 1) Since Delphi does not actually implement any of richedits features, merely wraps around them I should be in the clear to create a patch to wine to correct this functionality correct? and 2) What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).
Jacob, If you have any specific issues with wine's richedit control, you can always file a bug on bugs.winehq.org (and be sure to mark it as in the wine-richedit component). I haven't personally tried any api spy programs, so I can't vouch for them - but I've usually had success with just using the environmental variable WINEDEBUG ("WINEDEBUG=+richedit wine application.exe"). If you have any questions about how the richedit component works, feel free to ask me directly. When making changes, we encourage writing tests (see the dlls/riched20/tetsts folder) to demonstrate that the new behavior is, in fact, the correct behavior. Also, when you make a change make sure to run the tests already there to make sure you haven't caused any existing tests to fail. Thanks, --Matt
I'm not yet sure what the specific issue is with the richedit control yet, Its not behaving as it should in regards to saving information to a database in delphi (very delphi specific), So its going to take a lot of testing and debugging to determine where the fault lies exactly (if i replace riched20.dll with the one from the native msi installer it works fine). Just coming up with a test case I can submit will be a feat on its own considering how many layers I have to dig through, I have to look at my useage of TDBRichEdit, TDBRichEdit's use of TCustomRichControl and TCustomRichControl's use of the windows api to pin it down to any one specific thing, hence the vague description I gave of "weirdness". All in all considering my small program is dependant on ~50 thousand lines of delphi code and my using wine in a production system with this program only uncovering one small bug relating to richedit, I am quite impressed with wine.
On 1/20/07, Matt Finnicum mattfinn@gmail.com wrote:
Jacob, If you have any specific issues with wine's richedit control, you can always file a bug on bugs.winehq.org (and be sure to mark it as in the wine-richedit component). I haven't personally tried any api spy programs, so I can't vouch for them - but I've usually had success with just using the environmental variable WINEDEBUG ("WINEDEBUG=+richedit wine application.exe"). If you have any questions about how the richedit component works, feel free to ask me directly. When making changes, we encourage writing tests (see the dlls/riched20/tetsts folder) to demonstrate that the new behavior is, in fact, the correct behavior. Also, when you make a change make sure to run the tests already there to make sure you haven't caused any existing tests to fail. Thanks, --Matt
Jacob Alberty wrote:
What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).
SPY++, at least older versions, work fine under Wine.
Hi,
On Fri, Jan 19, 2007 at 02:12:49PM -0800, Duane Clark wrote:
Jacob Alberty wrote:
What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).
SPY++, at least older versions, work fine under Wine.
He most likely isn't talking about a message spy (i.e. SPY++), but about API tracers. apispy32 (IIRC) was one of the better API tracers on Windows. On Wine you just use WINEDEBUG=+relay and be done with it (unless you need further channels for specific Windows subsystems).
Andreas Mohr
I'm aware of the WINEDEBUG stuff, just wanted to use something that gives me uniform results, the data it outputs is the same on wine as windows, to speed up comparison I've been going through a WINEDEBUG=+all and have found some points of interest, I just need data to compare that to on a real windows machine (which I am currently setting up in a vm) This project is ultimately going to be moved to lazarus so that I can have a native solution, however wine is damned close to perfect with the corefonts package, a little config tweaking and riched20.dll from the nativemsi installer (which by the way the instructions at http://wiki.winehq.org/NativeMsi) have been failing for me as of wine 0.9.27(tested on 0.9.28 and 0.9.29 still didnt work) fails when i run instmsia.exe with "wine: Unimplemented function mscoree.dll.GetCORSystemDirectory called at address 0x60368820 (thread 0013), starting debugger... Unhandled exception: unimplemented function mscoree.dll.GetCORSystemDirectory called in 32-bit code (0x603688a2). " I have been extracting riched20.dll with cabextract for use.
On 1/20/07, Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
Hi,
On Fri, Jan 19, 2007 at 02:12:49PM -0800, Duane Clark wrote:
Jacob Alberty wrote:
What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).
SPY++, at least older versions, work fine under Wine.
He most likely isn't talking about a message spy (i.e. SPY++), but about API tracers. apispy32 (IIRC) was one of the better API tracers on Windows. On Wine you just use WINEDEBUG=+relay and be done with it (unless you need further channels for specific Windows subsystems).
Andreas Mohr
On Sa, 2007-01-20 at 17:29 +0000, Jacob Alberty wrote:
GetCORSystemDirectory
You need a newer wine: http://www.winehq.com/pipermail/wine-cvs/2006-December/028789.html
You are correct, I thought I remembered having that issue with 0.9.29 but apparently i was wrong, I tested against the latest git repository and nativemsi works. In the meantime I have managed to narrow the problem down to about 10 lines of code within the VCL and hope to have some code to exhibit the bug soon so that I can file a proper bug report.
On 1/21/07, Detlef Riekenberg wine.dev@web.de wrote:
On Sa, 2007-01-20 at 17:29 +0000, Jacob Alberty wrote:
GetCORSystemDirectory
You need a newer wine: http://www.winehq.com/pipermail/wine-cvs/2006-December/028789.html
--
By by ... Detlef
On So, 2007-01-21 at 12:54 +0000, Jacob Alberty wrote:
I have managed to narrow the problem down to about 10 lines of code within the VCL and hope to have some code to exhibit the bug soon so that I can file a proper bug report.
Great. This would help wine, when the VCL of Delphi works with less problems.
-
Andreas Mohr -
Detlef Riekenberg -
Duane Clark -
Jacob Alberty -
Matt Finnicum