Re: Please help me with document extraction.
On 02/28/2011 11:34 AM, André Hentschel wrote: Am 28.02.2011 17:20, schrieb Max TenEyck Woodbury: I think the idea of building upon the existing documentation somewhere else has a better chance than the deal on the 100 Frankly, I believe embedded documentation is the way to go. It is _not_ a panacea, but it is better than trying to maintain a separate set of functional documentation. I have seen cases where it worked. Not great but OK. I tried the separate document approach and got _very_ frustrated, and _no_one_ was really interested. Yeah, so let's see how interested people will be in the new aproach. (Also OK might not be enough for Wine) Hmm. First, it is _not_ a new approach. It has literally decades of application. I first encountered it in the '80s and it was well entrenched even then. Such people as D. Knuth have much to say on the subject. It is not even new to Wine. There is a lot of embedded documentation already. It just is not being maintained. Second, OK is better than nothing. I say it is OK because I have actually used such a system. It is a pain to maintain, but the results are usually very good. While the stuff I did never reached the public (It got hung at the informal Q/A stage), other similar material was sold at a profit and was generally rated as very good to excellent. Again, the reason I call it OK is because of the amount of work required. Max
Re: hhctrl.ocx: Decode HTML entities in contents and index
Owen Rudge oru...@codeweavers.com writes:
+static int cmp(const void *key, const void *element)
+{
+HtmlEntity *entity = (HtmlEntity *) element;
+return strncmpW((LPCWSTR) key, entity-string, lstrlenW(entity-string));
+}
This won't work.
--
Alexandre Julliard
julli...@winehq.org
Re: Please help me with document extraction.
On 2 March 2011 00:32, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: First, it is _not_ a new approach. It has literally decades of application. I first encountered it in the '80s and it was well entrenched even then. Such people as D. Knuth have much to say on the subject. I don't think anyone is arguing that it is a new concept, or even that it is a bad idea. It is not even new to Wine. There is a lot of embedded documentation already. It just is not being maintained. I think what's important to note is that there's a big difference between documenting Wine and documenting the API that Wine implements. If it makes sense for a 1 or 2 line documenting comment to go in to the code that explains the purpose of a function or a variable, then I'm sure AJ would not have an issue with that; but if you're looking at sticking the MSDN articles for win32/win64 into the Wine source, then that's: * bloating the code; * difficult to maintain (i.e., when MS decides to arbitrarily change the way the API works); * not necessary; and * generally a bad idea
Re: USB Osciloscope
I have a USB osciloscope (Link Instruments DSO 8002) that I am quite motivated to get working in wine. I have followed the instructions to install the USB patches. The osciloscope software works fine in demo mode, but it still cannot find the device. I have spent some time messing around with this, but I am new to wine, so I am a little lost. I am a half decent c programmer, so If somebody could point me in the right direction I should be able to get this working. I have gotten error message usbd.sys failed to load. I don't know if this program requires functions that wine does not support or I have just failed to install something correctly. I have attached lsusb and winedump -x output Any help would be greatly appreciated. usbd.sys sounds like a kernel driver. I'm not sure those are supported, even for USB. I had a logic analyzer that I managed to get working (sort of - the GUI did not work well with Wine). It used the FTDI drivers, so I found Linux version of the same drivers, and created a winelib wrapper for them under the same name as the Windows version. Your driver seems to be for a driver called ezusb. Try finding linux drivers for them (ezusb linux drivers returned http://www.linux-usb.org/ezusb/, for example. There is also http://www.cypress.com/?id=4rID=29746). Hope this helps, Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: WineHQ Bug 26271
Andreas Bierfert andreas.bierf...@lowlatency.de wrote: could you please stop arguing about the validity of the bug. What you are stating in comment 6 is really not exclusive. The Fedora wine packages are in fact 'prepackaged binary'. Using the term 'prepackaged binary' doesn't make the package suddenly valid for WineHQ bugzilla, since it clearly contains not supported patches. Same applies for instance to crossover, ies4linux, wineskin or any other. For the Fedora users pulse support in wine is an important feature. This is why the patches are in the Fedora build in the first place. I'd much rather have them included with upstream... Maybe sometime wine will gain openal support for audio input/output and this issue will go away. Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by including such patches - he/she should take the full resposibility for that, including accepting bug reports for his package. If he/she doesn't want to carry the support burden then using Wine source without any custom patches is the way to go. -- Dmitry.
