December 2001 - Wine-Devel - list.winehq.org

Re: Mixed-mode CD Labels

by David Elliott

On 2001.12.30 03:34 Chris Green wrote: > If anyone has an odd CD lying around, they can email me the first 65536 > bytes > of the CD (hopefully no vendor will care about copyright on their volume > descriptors!) so I can compare the structure of the volume descriptors - > I've > got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 > count=1' and compress the result before emailing it to me :) > hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? Maybe it doesn't make a damn bit of difference, but as the blocksize on cds is 2048 bytes I think it makes more sense to say gimme the first 32 2048-byte sectors. -Dave

Dec. 30, 2001

Re: Mixed-mode CD Labels

by Chris Green

On Friday 28 December 2001 21:38, Andreas Mohr wrote: > On Fri, Dec 28, 2001 at 09:24:14PM +1000, Chris Green wrote: > > On Friday 28 December 2001 20:24, Andreas Mohr wrote: > I think what should be done is to find out which mixed-mode CDs exactly are > "special" and which ones aren't. > > I guess it might be music CDs with builtin biography data/programs often > that are problematic. > > If you get hold of such CDs, then you need to experiment with > CDROMREADMODE2, CDROMREADMODE1 and/or CDROMREADRAW ioctl()s > (in /usr/include/linux/cdrom.h) to get back sector data. > I already verified once that you can get the CD label of "problematic" > mixed-mode CDs this way. > I couldn't figure out the mechanism that e.g. Windows uses to calculate > the serial number of these CDs, though. > > You might probably want to figure out a way to have misc/cdrom.c > also support label and serial reading of problematic mixed-mode CDs, in a > modular way (i.e. one that doesn't look too awful code-wise ;) Ok - I've been doing some serious experimenting here, including reading the iso 9660 spec :) I've found some interesting things too. First, it seems that some CD's don't just store the 'best' data in higher-numbered volume descriptors. Some seem to store 'everything' in the type 1 (primary) descriptor, and only store the modified info in the type 2 (secondary) descriptor. So the routine CDROM_Data_FindBestVoldesc (it returns the highest-numbered descriptor) might need some rethinking... Secondly, I found a real curiosity in one particular CD: Microsoft's Multimedia Beethoven (about 1992) isn't ISO9660 at all. It's a mixed mode CD, and is readable in Windows, as well as Wine, but the label is screwy (Windows XP gets it wrong too). Instead of using the specification identifier 'CD001' (ISO9660) it uses 'CDROM' and has two dwords stored at the start of the volume descriptor, as well as having a few other discrepancies. I have no conclusive proof as to what specification it's written, but I'm guessing its possibly the original High Sierra format, or perhaps an even earlier, semi-proprietary, spec. Either way, it makes me wonder whether some of the 'strange' mixed-mode CDs are of a similar nature. Anyway, what I'm thinking is to rewrite the code that deals with CD labels to take into account what I've found so far - I'll also include support to get the label from the 'CDROM' type I've found, so we'll have the right label for that CD too. Quite possibly, that'll fix the 'strange' mixed mode CD's too. If anyone has an odd CD lying around, they can email me the first 65536 bytes of the CD (hopefully no vendor will care about copyright on their volume descriptors!) so I can compare the structure of the volume descriptors - I've got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 count=1' and compress the result before emailing it to me :) regards Chris Green

Dec. 30, 2001

Re: Using windows dlls in unix shared libraries

by lawson_whitney＠juno.com

On Fri, 28 Dec 2001, Robert Jonsson wrote: > Hi all, > > I just subscribed to this list, I hope my questions aren't evidently > answered elsewhere, I tried to do some homework browsing the docs and > parts of the mailing list, but then again I'm no pro so I might have > missed it. > > The background story: > There is a plugin system for professional audio applications in Windows > called VST. I suppose it does pretty much the same job as a multimedia > codec. With the exception that they have internally generated GUIs! > Perhaps a winamp plugin would be the closest match. > There is a similar format in Linux called LADSPA (www.ladspa.org) > Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. > > The question: > I don't know that much about Wine internals, but all the example > applications I've looked at use the wine executable as boot loader. Does I thought to quibble with that, but it is a pretty fair analogy after all. Wine (including wineserver and wine builtin dlls) is a *NIX application, but it does provide "OS" services. It sort of needs an address space or two to kick around if it is going to be able to load native dlls that are not relocatable, FI. > that mean that this is the only way to start a wine application? Well, something has to be sure the wineserver is started. > The way I'd like to use it is like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - > VSTplugin Can your ladspaplug not fork and exec wine to run your vst wrapper? > > A possible solution would be to startup the VSTplugin in another > application and do IPC between the LADSPAplugin and the > VSTplugin-proxyhost. > Like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> > winebased_VSThost (LoadLibrary vstplugin) - VSTplugin > This does however seem akward... Is it possible to do it in an easier way? There isn't all that much to the wine executable these days. Most of Wine is in the builtin dlls and the wineserver. Have a look at <wine>/miscemu/main.c. If you think you can get that to run inside your plugin, maybe you can. Codeweavers did a crossover plugin whosis for linux browsers, I think, that would have had to address the problems. Lawson

Dec. 29, 2001

Re: We *really* need a development model change !

by Jeremy White

Andriy (and all), I think you have dismissed winetest much too quickly. We spent a considerable amount of energy thinking about a test harness (largely because one of our investors felt passionately that it was vital), so not only did we have the public conversations you saw on wine-devel, we here at CodeWeavers also had some lengthy private conversations. I entered that process feeling much as you do: that 'C' based tests were the way and the truth and the light. I was persuaded that a Perl based test was, in fact, a viable alternative, if not a better alternative. Several points: 1. John Sturtz worked very hard to make the Perl code able to take callbacks. AFAIK, it does that. 2. The Perl code makes it easy to do pattern matching, hex dumps, and general text manipulation, which is a good thing. 3. Perl is really easy to install and use in Windows; writing these tests in Windows is a total snap, and, I would argue, Windows is exactly where the tests should be written. All that aside, I think the most important tasks are a simple set: 1. Modify the makefiles so that 'make test' (or make regress, or pick your poison) does something interesting, and does so without much hassle. 2. Define a standard for how tests should work. For example, if I wanted to write a test for FunctionFoo(), I should be able to create wine/programs/winetest/tests/foo.pl, add 'foo.pl' to winetest/tests/Makefile.in, and my test should automatically become part of the regression suite. (Note that adding tests/foo.c is just as trivial). I believe that the defacto standard chosen at this point is that a test prints 'OK' if all went well, and it doesn't on error, and prints some clue as to what went wrong. 3. Add a section to the documentation on how to do the same. In my not so humble opinion, that is a very straightforward task, that shouldn't take very long, and would be an excellent beginning for shifting the development model. Once we have in place the concept of a 'make regress', we can start expanding on that to roll in new testing tools; I just think it's a mistake to arbitrarily discard a perfectly useful tool. Jer Andriy Palamarchuk wrote: > Simplicity is one of the goals of the testing > framework, but besides being simple the framework > should be powerful enough for such big project. > > I'm looking for existing library which would suit our > needs. > > Unit test framework "Check" looks promising. It > provides many features which I'd love to use for our > tests, including: > - protection of the test address space - tests crashed > do not put down the whole test suite and are reported. > At the same time you can request to run tests in the > same address space what is good for debugging. > - grouping tests in suites, tree-like grouping of the > test suites. You can choose to run only subset of the > tests > - having "set up" and "tear down" sections which can > be used to set up tests and free resourses after. > - a few forms of output - from silent to detailed > > Individual test looks like (section from manual): > > START_TEST(test_create) > { > fail_unless (money_amount(five_dollars) == 5, > "Amount not set correctly on creation"); > fail_unless > (strcmp(money_currency(five_dollars),"USD") == 0, > "Currency not set correctly on creation"); > } > END_TEST > > They also give information how to configure the tests > with autoconf. > > The issues which need to be resolved: > 1) License - GPL. Is it Ok to have the test suite > under GPL? > 2) Environment - POSIX. The library uses POSIX calls > to manage processes, in particular functions fork, > _exit, write, read, close, getppid, getpid, pipe. > Calls "fork" , "_exit" and "getppid" are used only > when test runs in FORK mode. We don't need to have > address space protection under Windows - tests there > should not crash. > The rest of functions are used for communication > between the test launcher and tests and can be > implemented with using corresponding Win32 calls. > After implementing these changes the framework can be > used in pure Win32 environment, without Cygwin. > > Let me know if you are interested. I'll start to work > on the port. Meantime we can start to use the > framework under Wine and on Windows with Cygwin. > > More information about Check you can find here: > http://check.sourceforge.net/ - home page > http://sourceforge.net/project/showfiles.php?group_id=28255 > - tutorial > > Thanks, > Andriy Palamarchuk > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com > >

Dec. 29, 2001

Re: Getting "Practice Exam" software working

by Andreas Mohr

On Fri, Dec 28, 2001 at 04:44:17PM -0700, Dax Kelson wrote: > > We have a training room full of students who are taking a cisco networking > design class. The class is basically all lecture so they don't normally > use a computer, but tomorrow the students need to take a practice exam. > > The student workstations are running Red Hat Linux 7.2. > > Their student books come with a CDROM with a practice exam program that > is, of course, a windows app. > > I've tried with the Wine that shipped with RH7.2, todays CVS snapshot, and > Codeweaver's preview 5 all with the same results. > > It *almost* works. I would rather get it working so we don't have install > windows just for them to run this one app. www.winehq.com/Trouble/ "how to get stuff working" or so should help. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 29, 2001

Getting "Practice Exam" software working

by Dax Kelson

We have a training room full of students who are taking a cisco networking design class. The class is basically all lecture so they don't normally use a computer, but tomorrow the students need to take a practice exam. The student workstations are running Red Hat Linux 7.2. Their student books come with a CDROM with a practice exam program that is, of course, a windows app. I've tried with the Wine that shipped with RH7.2, todays CVS snapshot, and Codeweaver's preview 5 all with the same results. It *almost* works. I would rather get it working so we don't have install windows just for them to run this one app. The problem starts up ok as seen in the screenshots 1 through 3 below. http://www.gurulabs.com/files/snapshot1.png http://www.gurulabs.com/files/snapshot2.png http://www.gurulabs.com/files/snapshot3.png http://www.gurulabs.com/files/snapshot4.png <- Problem here The problem is the sample questions and answers don't show up. http://www.gurulabs.com/files/snapshot5.png The "exhibits" seem to work fine. I'm using 100% builtin. There are no warnings or outputs that are displayed when exam question window starts. Any help would be greatly appreciated. Please save me from having to install windows on 13 computers. :) Dax Kelson

Dec. 28, 2001

Using windows dlls in unix shared libraries

by Robert Jonsson

Hi all, I just subscribed to this list, I hope my questions aren't evidently answered elsewhere, I tried to do some homework browsing the docs and parts of the mailing list, but then again I'm no pro so I might have missed it. The background story: There is a plugin system for professional audio applications in Windows called VST. I suppose it does pretty much the same job as a multimedia codec. With the exception that they have internally generated GUIs! Perhaps a winamp plugin would be the closest match. There is a similar format in Linux called LADSPA (www.ladspa.org) Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. The question: I don't know that much about Wine internals, but all the example applications I've looked at use the wine executable as boot loader. Does that mean that this is the only way to start a wine application? The way I'd like to use it is like this: Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - VSTplugin A possible solution would be to startup the VSTplugin in another application and do IPC between the LADSPAplugin and the VSTplugin-proxyhost. Like this: Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> winebased_VSThost (LoadLibrary vstplugin) - VSTplugin This does however seem akward... Is it possible to do it in an easier way? Btw, I know about the avifile project, don't know the history but it is based on wine right? However, to my knowledge avifile supports only a very limited amount of API calls, ie no graphics/window calls (perhaps except some trivial ones). Which would probably make it pretty hard to implement the above...

Dec. 28, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

Simplicity is one of the goals of the testing framework, but besides being simple the framework should be powerful enough for such big project. I'm looking for existing library which would suit our needs. Unit test framework "Check" looks promising. It provides many features which I'd love to use for our tests, including: - protection of the test address space - tests crashed do not put down the whole test suite and are reported. At the same time you can request to run tests in the same address space what is good for debugging. - grouping tests in suites, tree-like grouping of the test suites. You can choose to run only subset of the tests - having "set up" and "tear down" sections which can be used to set up tests and free resourses after. - a few forms of output - from silent to detailed Individual test looks like (section from manual): START_TEST(test_create) { fail_unless (money_amount(five_dollars) == 5, "Amount not set correctly on creation"); fail_unless (strcmp(money_currency(five_dollars),"USD") == 0, "Currency not set correctly on creation"); } END_TEST They also give information how to configure the tests with autoconf. The issues which need to be resolved: 1) License - GPL. Is it Ok to have the test suite under GPL? 2) Environment - POSIX. The library uses POSIX calls to manage processes, in particular functions fork, _exit, write, read, close, getppid, getpid, pipe. Calls "fork" , "_exit" and "getppid" are used only when test runs in FORK mode. We don't need to have address space protection under Windows - tests there should not crash. The rest of functions are used for communication between the test launcher and tests and can be implemented with using corresponding Win32 calls. After implementing these changes the framework can be used in pure Win32 environment, without Cygwin. Let me know if you are interested. I'll start to work on the port. Meantime we can start to use the framework under Wine and on Windows with Cygwin. More information about Check you can find here: http://check.sourceforge.net/ - home page http://sourceforge.net/project/showfiles.php?group_id=28255 - tutorial Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 28, 2001

Re: Mixed-mode CD Labels

by Chris Green

On Friday 28 December 2001 21:38, Andreas Mohr wrote: > > I guess it might be music CDs with builtin biography data/programs often > that are problematic. > > If you get hold of such CDs, then you need to experiment with > CDROMREADMODE2, CDROMREADMODE1 and/or CDROMREADRAW ioctl()s > (in /usr/include/linux/cdrom.h) to get back sector data. > I already verified once that you can get the CD label of "problematic" > mixed-mode CDs this way. > I couldn't figure out the mechanism that e.g. Windows uses to calculate > the serial number of these CDs, though. > > You might probably want to figure out a way to have misc/cdrom.c > also support label and serial reading of problematic mixed-mode CDs, in a > modular way (i.e. one that doesn't look too awful code-wise ;) Thanks Andreas. I'll do some investigating! regards Chris Green

Dec. 28, 2001

Re: Mixed-mode CD Labels

by Andreas Mohr

On Fri, Dec 28, 2001 at 09:24:14PM +1000, Chris Green wrote: > On Friday 28 December 2001 20:24, Andreas Mohr wrote: > > I know for a fact that you need special raw sector ioctl()s at least for > > certain mixed-mode CDs... > > Yeah I assumed there must have been something like that going on - I couldn't > think of any other reason why it wouldn't have been done. Right :) There are problems at least with certain mixed-mode CDs. > I don't know - does it make sense for wine to support something that seems to > work at least some of the time, as opposed to not supporting it at all? I think what should be done is to find out which mixed-mode CDs exactly are "special" and which ones aren't. > If not, are there any CDs in particular that you know of, that have the > requirement for a raw ioctl() read, I might have here, so I could experiment > with them? I guess it might be music CDs with builtin biography data/programs often that are problematic. If you get hold of such CDs, then you need to experiment with CDROMREADMODE2, CDROMREADMODE1 and/or CDROMREADRAW ioctl()s (in /usr/include/linux/cdrom.h) to get back sector data. I already verified once that you can get the CD label of "problematic" mixed-mode CDs this way. I couldn't figure out the mechanism that e.g. Windows uses to calculate the serial number of these CDs, though. You might probably want to figure out a way to have misc/cdrom.c also support label and serial reading of problematic mixed-mode CDs, in a modular way (i.e. one that doesn't look too awful code-wise ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 28, 2001