Re: Can I do this in WINE?
Vitaliy Margolen wrote: > Bret Comstock Waldow wrote: >> Vitaliy Margolen wrote: >>> Bret Comstock Waldow wrote: I ONLY want to write a Windows app I can install on my OWN copy of Tablet XP on my OWN Tablet PC and then run from Linux via WINE. >>> So you want that everyone drop everything they are doing and start >>> doing something that no one else can possibly use? Because it's either >>> illegal, too costly or depends on hardware that non one has? What a >>> wonderful idea! >> No, I want to develop a solution that anyone who has a Tablet PC can use >> to remain in Linux/Unix while using their OWN Tablet PC and the legal >> copy of Tablet XP that is licensed for that actual PC, and I want to >> tell others how to do it so they can for themselves. > In your solution you had 2 windows copies running at the same time. > That you can't do with only one license. I most certainly do not have two copies of Windows running at the same time with this new proposal, anymore than there are ANY copies of Windows running if I run Notepad off my disk in Linux via the WINE app. I install a COM app I write on my Tablet XP, shut down Tablet XP, and then boot Linux and run the app off the disk from Linux, just like we do when we run a copy of Notepad via WINE in Linux, or a game, or Word, off the Windows install partition, without running the full copy of Windows that is on the partition. My CURRENT .NET server based solution DOES involve a running copy of Tablet XP, on the hardware it's licensed to be installed on, accessible on a network to the person who is legally entitled to access it over the network, just as Microsoft's license says they may. It is even possible to load the local install of Windows right off it's partition in VMware, although it is an advanced use of VMware - and only one copy is running, and it's always running on the hardware it's actually licensed for - never anywhere else. Cheers, Bret
Re: Can I do this in WINE?
On Sat, May 24, 2008 at 12:39 AM, Bret Comstock Waldow <[EMAIL PROTECTED]> wrote: > Vitaliy Margolen wrote: >> Bret Comstock Waldow wrote: >>> I ONLY want to write a Windows app I can install on my OWN copy of >>> Tablet XP on my OWN Tablet PC and then run from Linux via WINE. >> >> So you want that everyone drop everything they are doing and start >> doing something that no one else can possibly use? Because it's either >> illegal, too costly or depends on hardware that non one has? What a >> wonderful idea! > No, I want to develop a solution that anyone who has a Tablet PC can use > to remain in Linux/Unix while using their OWN Tablet PC and the legal > copy of Tablet XP that is licensed for that actual PC, and I want to > tell others how to do it so they can for themselves. > > If it's legal for me to release the actual binaries to do that under a > free license (I'm using the Modified BSD license for my current .NET > server), then I will. If it's only legal to release the source code or > instructions under a free license then that's what I'll publish, and > people can write and compile their own, so they can use everything they > have paid for in a legal way. > > And you didn't address why it's acceptable for the WINE project to tell > people to use native .dlls in WINE without loading a full session of > Windows, but not acceptable for me. > > Can you speak to that, please? Is WINE itself breaking the law, and > what is the difference to what I am thinking of if the project is not? > Wine is software...not sure how 'it' can break the law. There's a vast difference between a software project, developing for that software, and using that software. A person using native Windows DLLs with Wine may be violating copyright law or the MS EULA if they don't own a licensed copy of Windows. We only advise licensed users of Windows to use their DLLs in Wine, and even then its' only as a last resort because it's detrimental in the long run to the project (developmentally, not legally). http://wiki.winehq.org/FAQ#head-d9796202650e186ec37698c0c8d2a18bebf6862c -- James Hawkins
Re: Can I do this in WINE?
Bret Comstock Waldow wrote: > Vitaliy Margolen wrote: >> Bret Comstock Waldow wrote: >>> I ONLY want to write a Windows app I can install on my OWN copy of >>> Tablet XP on my OWN Tablet PC and then run from Linux via WINE. >> So you want that everyone drop everything they are doing and start >> doing something that no one else can possibly use? Because it's either >> illegal, too costly or depends on hardware that non one has? What a >> wonderful idea! > No, I want to develop a solution that anyone who has a Tablet PC can use > to remain in Linux/Unix while using their OWN Tablet PC and the legal > copy of Tablet XP that is licensed for that actual PC, and I want to > tell others how to do it so they can for themselves. In your solution you had 2 windows copies running at the same time. That you can't do with only one license. > And you didn't address why it's acceptable for the WINE project to tell > people to use native .dlls in WINE without loading a full session of > Windows, but not acceptable for me. That's up to people to decide what they do and legality of it. If you read some posts where people suggesting use of native dlls - that's not a _project_ telling everyone to use those dlls. > Is WINE itself breaking the law, and what is the difference to what I am > thinking of if the project is not? Wine itself DOES NOT break the law. Nor is it's intention to break the law in any way shape or form. What you proposing - does. It seems you missing the whole point of the Wine project. Wine's objective is to run windows programs _WITHOUT_ windows. So no one is obligated to pay m$ tax on their hardware. Designing something that runs on Wine and requires that windows is absolutely wrong. Anyway. You are welcome to send patches that implement required functionality in Wine (after the wine-1.0 is out of course). Vitaliy.
Re: Can I do this in WINE?
Vitaliy Margolen wrote: > Bret Comstock Waldow wrote: >> I ONLY want to write a Windows app I can install on my OWN copy of >> Tablet XP on my OWN Tablet PC and then run from Linux via WINE. > > So you want that everyone drop everything they are doing and start > doing something that no one else can possibly use? Because it's either > illegal, too costly or depends on hardware that non one has? What a > wonderful idea! No, I want to develop a solution that anyone who has a Tablet PC can use to remain in Linux/Unix while using their OWN Tablet PC and the legal copy of Tablet XP that is licensed for that actual PC, and I want to tell others how to do it so they can for themselves. If it's legal for me to release the actual binaries to do that under a free license (I'm using the Modified BSD license for my current .NET server), then I will. If it's only legal to release the source code or instructions under a free license then that's what I'll publish, and people can write and compile their own, so they can use everything they have paid for in a legal way. And you didn't address why it's acceptable for the WINE project to tell people to use native .dlls in WINE without loading a full session of Windows, but not acceptable for me. Can you speak to that, please? Is WINE itself breaking the law, and what is the difference to what I am thinking of if the project is not? Cheers, Bret
Re: Can I do this in WINE?
Bret Comstock Waldow wrote: > I ONLY want to write a Windows app I can install on my OWN copy of > Tablet XP on my OWN Tablet PC and then run from Linux via WINE. So you want that everyone drop everything they are doing and start doing something that no one else can possibly use? Because it's either illegal, too costly or depends on hardware that non one has? What a wonderful idea! Vitaliy.
Re: Can I do this in WINE?
Vitaliy Margolen wrote: > Bret Comstock Waldow wrote: >> Otherwise, I need to know about the legality, and practicality, of a >> scheme such as I am proposing above. I'm hoping for comment, pointers, >> and perhaps help about writing it. > > You have to have valid _retail_ license of whatever windows version > parts of which you want to use with Wine. > > You can only use OEM version if you using the same hardware your > license came with. > > This makes completely impractical for anyone to use such a setup. Wine > is made to avoid having windows all together, not requiring it. > I ONLY want to write a Windows app I can install on my OWN copy of Tablet XP on my OWN Tablet PC and then run from Linux via WINE. There are Universities that mandate Tablet computers for Faculty and Students, thus locking Linux from use in academic situations, which is one of the best arenas for development of Free Software handwriting recognition. I want to make it practical for anyone to remain in Linux (or Unix) all the time while using a Tablet computer. This would allow an eco-system of tablet functionality to develop, which in turn makes it more possible and more likely that someone will provide a solution to the central problem of handwriting recognition free from proprietary encumbrance. If someone wants to avoid using Windows, they should avoid using Windows programs, and instead use solutions that have no dependency on Windows, to make it entirely irrelevant. WINE is a compromise to allow people to use Windows programs without (all of) Windows, but it's not a solution, it's a stepping stone. That's what I am intending as well, but specifically for Tablet computers. I don't see an ethical difference between allowing the use of native ..dlls in WINE, and my own intentions, nor a legal one. If you can load native .dlls without running a full session of Windows in order to run a Windows program, why can't I? I would like an actual answer to that, as it seems to be the crux of the question. Or does WINE itself break the law by allowing the use of native .dlls without loading a full copy of Windows? Cheers, Bret
Re: Can I do this in WINE?
John Klehm wrote: > On Fri, May 23, 2008 at 8:58 PM, Bret Comstock Waldow <[EMAIL PROTECTED]> > wrote: > >> I will be very interested in looking at any open source handwriting >> recognition programs you can point me at. >> > Here's what I was able to dig up awhile back in regards to open source > handwriting recog of any kind (not saying I found everything by any > means): > > http://code.google.com/p/ocropus/ <= maybe the best handwriting recog engine? > I've had a half-an-hour look at this. I see the phrase "handwriting recognition" a lot, but no examples or discussion yet. > http://www.dklevine.com/general/software/tc1000/jarnal.htm <= closest > thing to onenote > Yes, and the handwriting recognition is entirely printed individual characters, and it's not particularly good. I don't think this is any reflection on the authors - handwriting recognition is one of the "hard" problems. But it doesn't provide sufficient support. > http://groundstate.ca/tabletsoft <= good summary of a bunch of programs > http://www.stressbunny.com/wayv/ > http://www.handhelds.org/projects/xscribble.html > http://www.etla.net/libstroke/ > All of these are printed individual character (or glyph) recognition systems, and thus seriously compromise notetaking and post-recognition tasks. >> Otherwise, I need to know about the legality, and practicality, of a >> scheme such as I am proposing above. I'm hoping for comment, pointers, >> and perhaps help about writing it. >> > If you are suggesting to use one copy of windows to serve > functionality for multiple users that might be on shaky legal ground, > IANAL though. > I don't know myself. The web has many examples, published with Microsoft's implicit (MVPs) or explicit consent (MS provides the examples themselves) of ink-on-the-web, including handwriting recognition. They're largely .NET, but not all. I'm not interested in providing this service for many users, however, I'm only interested in using it for myself, on my own Tablet computer, with my own licensed copy of Tablet XP. Here is the language from the eula: 1.4 Device Connections. You may permit a maximum of ten (10) computers or other electronic devices (each a "Device") to connect to the COMPUTER to utilize one or more of the following services of the SOFTWARE: File Services, Print Services, Internet Information Services, Internet Connection Sharing and telephony services. The ten connection maximum includes any indirect connections made through "multiplexing" or other software or hardware which pools or aggregates connections. This ten connection maximum does not apply to other uses of the SOFTWARE, such as synchronizing data between a Device and the COMPUTER, provided only one user uses, accesses, displays or runs the SOFTWARE at any one time. This Section 1.4 does not grant you rights to access a COMPUTER Session from any Device. A "Session" means any use of the SOFTWARE that enables functionality similar to that available to an end user who is interacting with the COMPUTER through any combination of input, output and display peripherals. 1.5 Remote Desktop/Remote Assistance/NetMeeting. The SOFTWARE contains Remote Desktop, Remote Assistance, and NetMeeting technologies that enable the SOFTWARE or applications installed on the COMPUTER (sometimes referred to as a host device) to be accessed remotely from other Devices. You may use the SOFTWARE's Remote Desktop feature (or other software which provides similar functionality for a similar purpose) to access a COMPUTER Session from any Device provided you acquire a separate SOFTWARE license for that Device. As an exception to this rule, the person who is the single primary user of the COMPUTER may access a Computer Session from any Device without acquiring an additional SOFTWARE license for that Device. When you are using Remote Assistance or NetMeeting (or other software which provides similar functionality for a similar purpose) you may share a Session with other users without any limit on the number of Device connections and without acquiring additional licenses for the SOFTWARE. For Microsoft and non-Microsoft applications, you should consult the license agreement accompanying the applicable software or contact the applicable licensor to determine whether use of the software with Remote Desktop, Remote Assistance, or NetMeeting is permitted without an additional license. Except as otherwise permitted by the NetMeeting and Remote Assistance features described above, a license for the SOFTWARE may not be shared or used concurrently on dif
Re: Can I do this in WINE?
Vitaliy Margolen wrote: > Bret Comstock Waldow wrote: > >> Otherwise, I need to know about the legality, and practicality, of a >> scheme such as I am proposing above. I'm hoping for comment, pointers, >> and perhaps help about writing it. >> > > Like Vitality said, the Wine project would like to avoid this, if possible. However, the statements made about the 'parts' of Windows you are using. If you are using a .dll that is available ONLY with a retail/OEM Windows package, you just might be violating the laws of your country. Here it is best to consult a copyright attorney before DOING ANYTHING. In the United States, copyright violations can be VERY expensive. If you get several of the United States government entities involved, fines can be very high and you can end up with a lengthy stay in one of the country's finer prisons. > You have to have valid _retail_ license of whatever windows version parts of > which you want to use with Wine. > Depends on where you are living. The European Union threw out most of the End User License Agreement as unenforceable. In the United States of America, your statement is completely true. However, it is best to avoid piracy if at all possible. > You can only use OEM version if you using the same hardware your license > came with. > Again, see above. However, if you are using a re-destributiable and it does not have the 'new' EULA, you can use the package with Wine. .NET 3 has the new EULA that states it MUST be used with Microsoft Windows and thus the Genuine check. > This makes completely impractical for anyone to use such a setup. Wine is > made to avoid having windows all together, not requiring it. > > Here, here. Let's build into Wine the functionality to support most popular Windows programs and rid ourselves of the need to rely on Windows .dll code. James McKenzie
Re: Can I do this in WINE?
Bret Comstock Waldow wrote: > Otherwise, I need to know about the legality, and practicality, of a > scheme such as I am proposing above. I'm hoping for comment, pointers, > and perhaps help about writing it. You have to have valid _retail_ license of whatever windows version parts of which you want to use with Wine. You can only use OEM version if you using the same hardware your license came with. This makes completely impractical for anyone to use such a setup. Wine is made to avoid having windows all together, not requiring it. Vitaliy.
Re: avifil32/tests: [2/2] Add a test for AVISaveOptions and fix thedetected crash
"Detlef Riekenberg" <[EMAIL PROTECTED]> wrote:
> - for (; nStreams > 0; nStreams--) {
> + for (nStreams--; nStreams >= 0; nStreams--) {
> if (ppOptions[nStreams] != NULL) {
>ppOptions[nStreams]->dwFlags &= ~AVICOMPRESSF_VALID;
Shouldn't this be
for (nStreams - 1; nStreams >= 0; nStreams--) {
instead?
--
Dmitry.
Re: Can I do this in WINE?
On Fri, May 23, 2008 at 8:58 PM, Bret Comstock Waldow <[EMAIL PROTECTED]> wrote: > I will be very interested in looking at any open source handwriting > recognition programs you can point me at. > Here's what I was able to dig up awhile back in regards to open source handwriting recog of any kind (not saying I found everything by any means): http://code.google.com/p/ocropus/ <= maybe the best handwriting recog engine? http://www.dklevine.com/general/software/tc1000/jarnal.htm <= closest thing to onenote http://groundstate.ca/tabletsoft <= good summary of a bunch of programs http://www.stressbunny.com/wayv/ http://www.handhelds.org/projects/xscribble.html http://www.etla.net/libstroke/ I had been hoping to eventually get inkobj in wine to use ocopus as the backend for handwriting but thats just a dream at this point. > Otherwise, I need to know about the legality, and practicality, of a > scheme such as I am proposing above. I'm hoping for comment, pointers, > and perhaps help about writing it. > If you are suggesting to use one copy of windows to serve functionality for multiple users that might be on shaky legal ground, IANAL though. Hope this helps, --John
Time to cull the changelog file
A while back, Alexandre promised to wipe the changelog file "when we hit 1.0 or when it hits 4 gigabytes, whichever comes first." Well, it's about time. I suggest removing all changes for entries earlier than Wine 1.0-rc1, as having it completely empty would be a bit silly. As for where to archive the old changes online, I'm not sure. Culling the changelog like this will reduce package size substantially. The text, even when compressed, is rather large. Thanks, Scott Ritchie
Re: Can I do this in WINE?
John Klehm wrote: > On Fri, May 23, 2008 at 8:17 AM, Bret Comstock Waldow <[EMAIL PROTECTED]> > wrote: > >> I have a Tablet PC, running Kubuntu, and I have just released a project >> on sourceforge to allow me to use the Microsoft hand writing >> recognition. The current approach uses a .NET server in IIS running on >> Tablet XP to provide the recognition. I would prefer to write a classic >> Windows program that accepts the polyline ink strokes, accesses the >> Tablet SDK & .dlls to recognize ink, and run that program in WINE >> directly in Linux without IIS and network connections. >> >> > > There is the very tiniest skeleton of inkobj.dll which unfortunately > is no where near enough to even let an ms ink program run let alone do > handwriting recognition. Also I'm unsure of how doable it is to run > .Net apps in wine yet. > > wintab32 works alright though, so perhaps you would be able to write a > wintab app which integrated with one of the open source handwriting > recognition programs (ocropus and others ill try and dig up the links > later if you are interested). > I will be very interested in looking at any open source handwriting recognition programs you can point me at. In order to be generally useful, the program must be able to recognize cursive handwriting, as then it can be used with a general note-taking application, such as the Tablet enabled PIMs (which is why I got interested in the first place) or an open source equivalent of OneNote. Xstroke uses the libstroke library to provide recognition of single-stroke characters, and while many of those glyphs look like their actual character, not all can. A person could learn to write a page full of individual glyphs (and read it), and then a program could use libstroke later to interpret (and thus search through) such pages of notes, but that's not the best solution. We need cursive natural handwriting recognition, and I have that in the licensed Tablet XP I have on my machine. There are many examples of "ink-on-the-web" published by Microsoft and their MVPs, and the license states I can connect to my copy of XP over the network to consume services provided by IIS, so I'm comfortable with my current solution. But it's not the most useful - it requires a virtualized copy of Tablet XP (or Vista) and that VM makes it cumbersome. There is apparently a legal basis for me to use WINE to run Notepad off my Windows partition. I want to write a Windows COM (Automation) app - no .NET - that I can install on my copy of Windows and then run via WINE, just as I do Notepad or Solitaire. The Tablet PC SDK appears at first look to allow such. If there is already a usable open source cursive handwriting recognition program, I'll be happy to use that and ditch Windows entirely. Otherwise, I need to know about the legality, and practicality, of a scheme such as I am proposing above. I'm hoping for comment, pointers, and perhaps help about writing it. Cheers, Bret
Regression in wined3d: Add read_from_framebuffer_texture which combines code from read_from_framebuffer (drawpixels) and LoadLocation.
Hi,
after investigating reports for the game 'World in Conflict', I identified the
following patch to cause the game graphics to freeze (ambient sounds are
still played though):
ba90a740beb9ce9a839cc843db8d87f5a37becdd is first bad commit
commit ba90a740beb9ce9a839cc843db8d87f5a37becdd
Author: Roderick Colenbrander <[EMAIL PROTECTED]>
Date: Sun Feb 10 22:20:15 2008 +0100
wined3d: Add read_from_framebuffer_texture which combines code from
read_from_framebuffer (drawpixels) and LoadLocation.
This makes the code easier to read and the pieces borrowed from
read_from_framebuffer are more correct than the code in LoadLocation.
:04 04 74e4bdc73e367c8f38cd3d0818df0fc86eb788bf
3e54409be7c9d2964efbf3d3c2f3d3b84a267047 M dlls
The freezes only seem to occur if the native (Windows) dxdiagn.dll is used, as
it lets the game properly detect the graphics card and thus enables
additional graphics options (highend shaders, high-res textures, etc.).
Apparently the freeze is only triggered with these options active.
The game uses events in its drawing code and ("always") hangs after the
following output:
fixme:d3d9:D3DPERF_BeginEvent (color 0x, name L"Update verlet
cloth") : stub
fixme:d3d9:D3DPERF_EndEvent (void) : stub
At one point, it was followed by this error:
err:d3d_surface:surface_prepare_system_memory Surface without memory or pbo
has SFLAG_INSYSMEM set!
The point of the freeze appears to depend on many factors. If I move the
camera around, it appears to freeze earlier than just letting the game run
(e.g. a replay of a match). But once the patch is excluded, the game no
longer freezes.
If more info is needed, please specify how I can obtain it.
--
Markus
Re: Readme: Updates needed
Austin English wrote: > Alexandre committed a few fixed to the README today, but I still see a > few things that may need fixing: > > ./tool/wineinstall - Has been mentioned to be deprecated a few times > in bugzilla. If it's deprecated, we need to remove it. If not, we need > to fix whatever it's doing wrong and stop discouraging its use. > > 3. REQUIREMENTS > Linux version 2.0.36 or above > FreeBSD 6.2 or later > Solaris x86 2.5 or later The last time I have asked about the supported Solaris version (free(NULL) == nop time; about 1.5 years ago) the answer was: it runs on Solaris 9 and 10 and could be made to compile on 8. > NetBSD-current > Mac OS X 10.4 or later > > Need to check these versions. FreeBSD should be 6.3, with patches, or > preferably 7.0. Others, I don't know. > > Lastly, the translated READMEs under /documentation likely need _a > lot_ of work. Those of you that are bilingual might take a stab at > it... > > There were a couple other minor things that I've sent a patch for: > urls lacking trailing backslash, mentioning version .9 instead of 1.0, > using solitare as an example program (which we don't include, so I > replaced with notepad), etc. bye michael
Readme: Updates needed
Alexandre committed a few fixed to the README today, but I still see a few things that may need fixing: ./tool/wineinstall - Has been mentioned to be deprecated a few times in bugzilla. If it's deprecated, we need to remove it. If not, we need to fix whatever it's doing wrong and stop discouraging its use. 3. REQUIREMENTS Linux version 2.0.36 or above FreeBSD 6.2 or later Solaris x86 2.5 or later NetBSD-current Mac OS X 10.4 or later Need to check these versions. FreeBSD should be 6.3, with patches, or preferably 7.0. Others, I don't know. Lastly, the translated READMEs under /documentation likely need _a lot_ of work. Those of you that are bilingual might take a stab at it... There were a couple other minor things that I've sent a patch for: urls lacking trailing backslash, mentioning version .9 instead of 1.0, using solitare as an example program (which we don't include, so I replaced with notepad), etc. -Austin
New winetricks 20080523: directx9, bugfixes
Another week, another winetricks. Changes since May 19's wine-devel annoucement: r52: - rotate sourceforge mirrors to avoid getting stuck on bad one - cope with users who rename c:/windows/Fonts to c:/windows/fonts - more conservative advice on sha1sum mismatches - handle bad exit status from /usr/bin/which on mac - cope with redhat.com sending decompressed files - use win2K when installing directx9 so it installs more stuff r50: - Added directx9 verb Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com
Re: Alternate shell?
Quoting Dan Kegel <[EMAIL PROTECTED]>: Not exactly wine but quite close: some people are trying to use KDE4 as the desktop for ReactOS: http://kde-reactos.sourceforge.net/ ... which mutates KDE into the "operating system", able to run with a Linux, BSD, Win32, Solaris, etc kernel.Crazy. > For a maximal dogfood experience, I was looking around > for a way to use a replacement Windows shell with > Wine as my desktop environment instead of gnome > or kde. > > So far, all the ones I've found are either broken, hard to use, > or just plain weird. > > I've been working through the list at > http://www.dmoz.org/Computers/Software/Operating_Systems/Microsoft_Windows/Software/Alternate_Shells/ > > http://www.astonshell.com/aston/ - couldn't figure out how to run it? > > http://www.emergedesktop.org/ - kind of works, but very minimal, no > start menu > > http://www.labyrinth.net.au/~mosses/rob/liteshell.html - works, but > very minimal, no start menu > > http://purels.org - no help, just exits, saying "ha ha, you didn't > configure me". Obviously not meant for me :-) > > http://www.lighttek.com/talisman.htm - pretty, but no Programs menu?! > (Maybe that's there but broken, wine bug?) > > http://www.sky.franken.de/explorer/download.html - ROS explorer - > prebuilt binary > there is 3 years out of date, doesn't work too well > > Anyone have a favorite I should try? > - Dan > > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Proposed indentation fixes
Alistair Leslie-Hughes wrote: > Hi Andrew, > I would do 1, and if you think that its wrong, add a comment email > asking > for double check. > > Best Regards > Alistair Leslie-Hughes Sounds good. Thanks, Alistair! -- Andy.
Re: Can I do this in WINE?
On Fri, May 23, 2008 at 8:17 AM, Bret Comstock Waldow <[EMAIL PROTECTED]> wrote: > I have a Tablet PC, running Kubuntu, and I have just released a project > on sourceforge to allow me to use the Microsoft hand writing > recognition. The current approach uses a .NET server in IIS running on > Tablet XP to provide the recognition. I would prefer to write a classic > Windows program that accepts the polyline ink strokes, accesses the > Tablet SDK & .dlls to recognize ink, and run that program in WINE > directly in Linux without IIS and network connections. > There is the very tiniest skeleton of inkobj.dll which unfortunately is no where near enough to even let an ms ink program run let alone do handwriting recognition. Also I'm unsure of how doable it is to run .Net apps in wine yet. wintab32 works alright though, so perhaps you would be able to write a wintab app which integrated with one of the open source handwriting recognition programs (ocropus and others ill try and dig up the links later if you are interested). --John
Can I do this in WINE?
I have a Tablet PC, running Kubuntu, and I have just released a project on sourceforge to allow me to use the Microsoft hand writing recognition. The current approach uses a .NET server in IIS running on Tablet XP to provide the recognition. I would prefer to write a classic Windows program that accepts the polyline ink strokes, accesses the Tablet SDK & .dlls to recognize ink, and run that program in WINE directly in Linux without IIS and network connections. I'm thinking of my legal dual-boot installation, and reaching over with WINE to run the app just as I run Notepad from the Windows install now. I'm a Java programmer by day, and I haven't programmed Windows COM before (much). I'd like comments and advice (even help) on doing this. All of this message is written by hand in Linux using the SHIP project (except copying and pasting this URL): https://sourceforge.net/projects/ship-project/ Thanks in advance for information, bret
Re: Alternate shell?
On Fri, May 23, 2008 at 6:12 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > I think we're going to want to add a start button and taskbar > to our builtin explorer. None of the replacements seem > to look anything like Windows XP, which is kind of what I'm > after. > - Dan > This sounds a lot like my idea: http://bugs.winehq.org/show_bug.cgi?id=11629 I first posted it on this list, and the consensus here was that Wine should not have a "usable interface" as I called it, because the right direction would be to strive for maximum integration. Then I was told I should have instead posted it on BugZilla, which resulted in the bug above. Remco
Re: unknown device issues after running winetest
Paul Vriens wrote:
> James Hawkins wrote:
>> On Fri, May 23, 2008 at 3:10 AM, Paul Vriens
>> <[EMAIL PROTECTED]> wrote:
>>> James Hawkins wrote:
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens
<[EMAIL PROTECTED]>
wrote:
> Alexander Morozov wrote:
>>> Can someone confirm that after running the devinst tests, the
>>> registry
>>> on
>>> Wine still shows these:
>>>
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS
>>> (and
>>> stuff below)
>>>
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and
>>> stuff
>>> below)
>>>
>>>
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
>>>
>>>
>>> -3F65-11DB-B704-0011955C2BDB} (and stuff below)
>> I can confirm this. Diff file with changes after running make
>> devinst.ok
>> is
>> attached.
>>
>>
> Ok, so at least it looks we are compatible with Windows :-)
>
> I will check out your suggestion about using SetupDiRemoveDevice (and
> maybe
> SetupDiRemoveDeviceInterface) to clean up the registry.
>
> I already found that it doesn't work on NT4 for everything as we
> have a
> bogus
> bogus entry (missing the ClassGUID value). This means you can't even
> enumerate
> this one and it won't be covered by the remove calls.
>
> So what about a cleanup_before function that gets rid of everything
> that's
> currently bogus in the registry? If we don't do this before we have to
> cater for
> existing keys in every test which will clutter the tests I think.
> If we
> really
> want to test existing keys we should do so a part of a normal test.
>
> After that cleanup_before is working we can change the tests to
> clean up
> after
> themselves.
>
Will the new 'cleanup after' code not delete these invalid entries?
One test run is fine to sacrifice for the sake of not cluttering up
the tests with temporary cleanup code.
>>> The problem is that we could have failures because of existing keys
>>> and we
>>> have to cater for that in every test maybe.
>>>
>>> I agree with you though and will first check if having the 'cleanup
>>> after'
>>> serves it's purpose (even if we have to run the test twice to
>>> actually see
>>> results).
>>>
>>> Could take a while though as I have to check which tests leaves what
>>> keys
>>> around. Then how I can get rid of them on every platform. Wine
>>> doesn't have
>>> the SetupDiRemove stuff yet btw.
>>>
>>
>> All I'm saying is that there shouldn't be a reason to have a hacky
>> pre-cleanup. All the cleanup that is needed for the tests should be
>> added, and after one round of failures, the next set of tests should
>> be clean.
>>
> I just had a check for the testRegisterAndGetDetail test on Vista (dunno
> about the other tests and platforms yet).
>
> I added the SetupDiRemoveDevice (as was suggested by Alexander) at the
> end of this test.
>
> On a clean registry this works out fine (one DeviceClasses key is left
> but that one can be deleted without having to fiddle with permissions).
>
> When I however first run the old tests (with leftovers in the registry)
> and then run the new test again the registry keys are still present.
> When I do the SetupDiRemoveDevice twice at the end of
> testRegisterAndGetDetail the registry keys get deleted again (not that
> DeviceClasses key again).
>
> So what would be a good approach? Just doing 2 SetupDiRemoveDevice's at
> the end to make sure old stuff is gone as well?
> Or doing one, check if the Enum keys is still present and then do a
> second SetupDiRemoveDevice (with a trace message for clarity)?
>
This is not going to be an easy thing.
Just did a test on W2K3 for the testRegisterDeviceInfo test.
On a clean registry (after a reboot) I can remove the device nicely right after
the test. Doing the tests again though fails unless I reboot. So some
information is stored somewhere (services.exe?).
When the tests are run a second time (without a reboot) the following key
structure is created:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\BOGUS\\Control
After a reboot the Control key is gone. We can now just remove this by using
SetupDiRemoveDevice.
So the scenarios:
After a reboot:
- clean registry
- first tests will succeed and reg keys can be deleted afterwards
- running the tests again will fail and create some regkeys that can't be
deleted with SetupDiRemoveDevice in that same session (needs a reboot).
- USB\BOGUS\\Control is present
- old tests have just been run and the system hasn't been rebooted since.
Our
new tests will fail.
- USB\BOGUS\ is present (but not the Control one)
- we can remove the keys with SetupDiRemoveDevice
- first tests will succeed and reg keys can be deleted afterwards
- running the tests again will fail.
And
Re: Alternate shell?
Dmitry Timoshkov skrev: > "Dan Kegel" <[EMAIL PROTECTED]> wrote: > >> For a maximal dogfood experience, I was looking around >> for a way to use a replacement Windows shell with >> Wine as my desktop environment instead of gnome >> or kde. > > Built-in Wine explorer does a lot of things which the replacements > won't do, like desktop window management and HAL support. Last time I checked, the HAL stuff was handled by mountmgr.sys
Re: Alternate shell?
Hello, what about asking the developer where he got his information? ;-) If I remember correctly, I found this logoff dialog function using Google on one of those "undocumented Windows 95" web pages when adding it to the original ROS Explorer. Regards, Martin Am 23.05.2008 um 06:37 schrieb Dmitry Timoshkov: > "Steven Edwards" <[EMAIL PROTECTED]> wrote: > >> Again, I think you should look at explorer-new. Its pretty close to >> working, I think the StartMenu and friends work. It is designed for >> Windows XP, does the Desktop, Start Menu, Taskbar, etc, is written in >> C, is LGPL and is written by a ReactOS developer that has not been >> blacklisted by Wine. I don't think it would be much trouble to merge >> the two. Except of course shell32 is where most of the explorer >> really >> lives and there is a lot of functionality missing in wine. Due to the >> ReactOS embargo, shell32 has started to fork quite a bit on the >> ReactOS side. >> >> http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/explorer-new/ > > Since ros explorer uses an undocumented shell32.LogoffWindowsDialog as > reported in http://bugs.winehq.org/show_bug.cgi?id=10006 it should be > enough to blacklist its developer. > > -- > Dmitry.
Re: unknown device issues after running winetest
> I just had a check for the testRegisterAndGetDetail test on Vista (dunno > about the other tests and platforms yet). > > I added the SetupDiRemoveDevice (as was suggested by Alexander) at the end > of this test. > > On a clean registry this works out fine (one DeviceClasses key is left but > that one can be deleted without having to fiddle with permissions). > > When I however first run the old tests (with leftovers in the registry) and > then run the new test again the registry keys are still present. > When I do the SetupDiRemoveDevice twice at the end of > testRegisterAndGetDetail the registry keys get deleted again (not that > DeviceClasses key again). > > So what would be a good approach? Just doing 2 SetupDiRemoveDevice's at the > end to make sure old stuff is gone as well? > Or doing one, check if the Enum keys is still present and then do a second > SetupDiRemoveDevice (with a trace message for clarity)? I think the second way is better. May be a number of Enum keys is equal a quantity of doing old test?
Re: Proposed indentation fixes
"Andrew Talbot" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi All, > > I'm intending to "correct" some indentation anomalies, and I propose to do > this in an "indiscriminate" way. In other words, I would set the > indentation to match what the code does now, without any interpretation of > what may have been intended. This means that something like > >if (a) >b; >c; > > would become > > 1) >if (a) >b; >c; > Hi Andrew, I would do 1, and if you think that its wrong, add a comment email asking for double check. Best Regards Alistair Leslie-Hughes
RE: Alternate shell?
Dmitry Timoshkov [mailto:[EMAIL PROTECTED] wrote: > Since ros explorer uses an undocumented > shell32.LogoffWindowsDialog as reported in > http://bugs.winehq.org/show_bug.cgi?id=10006 it should be > enough to blacklist its developer. If you google for LogoffWindowsDialog you find entries for a Wine hard stub and then two patches to ROS, one implementing a soft stub in ROS and the other adding a call to ExitProcess to this stub so the shutdown process can continue. Is this reverse engineering? Rolf Kalbermatter
Re: unknown device issues after running winetest
James Hawkins wrote:
> On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> James Hawkins wrote:
>>> On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <[EMAIL PROTECTED]>
>>> wrote:
Alexander Morozov wrote:
>> Can someone confirm that after running the devinst tests, the registry
>> on
>> Wine still shows these:
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
>> stuff below)
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
>> below)
>>
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
>> -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> I can confirm this. Diff file with changes after running make devinst.ok
> is
> attached.
>
>
Ok, so at least it looks we are compatible with Windows :-)
I will check out your suggestion about using SetupDiRemoveDevice (and
maybe
SetupDiRemoveDeviceInterface) to clean up the registry.
I already found that it doesn't work on NT4 for everything as we have a
bogus
bogus entry (missing the ClassGUID value). This means you can't even
enumerate
this one and it won't be covered by the remove calls.
So what about a cleanup_before function that gets rid of everything
that's
currently bogus in the registry? If we don't do this before we have to
cater for
existing keys in every test which will clutter the tests I think. If we
really
want to test existing keys we should do so a part of a normal test.
After that cleanup_before is working we can change the tests to clean up
after
themselves.
>>> Will the new 'cleanup after' code not delete these invalid entries?
>>> One test run is fine to sacrifice for the sake of not cluttering up
>>> the tests with temporary cleanup code.
>>>
>> The problem is that we could have failures because of existing keys and we
>> have to cater for that in every test maybe.
>>
>> I agree with you though and will first check if having the 'cleanup after'
>> serves it's purpose (even if we have to run the test twice to actually see
>> results).
>>
>> Could take a while though as I have to check which tests leaves what keys
>> around. Then how I can get rid of them on every platform. Wine doesn't have
>> the SetupDiRemove stuff yet btw.
>>
>
> All I'm saying is that there shouldn't be a reason to have a hacky
> pre-cleanup. All the cleanup that is needed for the tests should be
> added, and after one round of failures, the next set of tests should
> be clean.
>
I just had a check for the testRegisterAndGetDetail test on Vista (dunno about
the other tests and platforms yet).
I added the SetupDiRemoveDevice (as was suggested by Alexander) at the end of
this test.
On a clean registry this works out fine (one DeviceClasses key is left but that
one can be deleted without having to fiddle with permissions).
When I however first run the old tests (with leftovers in the registry) and
then
run the new test again the registry keys are still present.
When I do the SetupDiRemoveDevice twice at the end of testRegisterAndGetDetail
the registry keys get deleted again (not that DeviceClasses key again).
So what would be a good approach? Just doing 2 SetupDiRemoveDevice's at the end
to make sure old stuff is gone as well?
Or doing one, check if the Enum keys is still present and then do a second
SetupDiRemoveDevice (with a trace message for clarity)?
--
Cheers,
Paul.
Proposed indentation fixes
Hi All,
I'm intending to "correct" some indentation anomalies, and I propose to do
this in an "indiscriminate" way. In other words, I would set the
indentation to match what the code does now, without any interpretation of
what may have been intended. This means that something like
if (a)
b;
c;
would become
1)
if (a)
b;
c;
rather than
2)
if (a)
{
b;
c;
}
The advantages are that the code is "honest" and the existing behaviour is
preserved. The disadvantages are that if (2) were intended, it won't be
achieved here, and the corrected version will no longer "suggest" what was
really intended.
Is this "automatic" method still the way to go?
Thanks,
--
Andy.
Re: ddraw: Fixed in part regression bug #13277, retry
Please send test and patch in one patch file, or send them in different emails if a combined patch is too big(which surely isn't the case here)
rpcrt4 test failures
Hi Rob, I roughly found the reason of the rpcrt4:server test crashing for me. It crashes when it's trying to connect to localhost through the rpc 'tcp' transport. The crash is likely caused because it can't connect to the locally hosted test server the tcp way, and decides to bomb out instead. However it won't say it failed to connect, instead it crashes on the first test-case that uses rpc. I would rather not have the test crash, that would also obscure the possibility of running the other tests in that file. However I don't know why it fails to connect over tcp (netbios works fine). I disabled my firewall entirely, so it shouldn't be the cause of this failure. Could there be other restrictions in place? Cheers, Maarten
Re: unknown device issues after running winetest
James Hawkins wrote:
> On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> James Hawkins wrote:
>>> On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <[EMAIL PROTECTED]>
>>> wrote:
Alexander Morozov wrote:
>> Can someone confirm that after running the devinst tests, the registry
>> on
>> Wine still shows these:
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
>> stuff below)
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
>> below)
>>
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
>> -3F65-11DB-B704-0011955C2BDB} (and stuff below)
> I can confirm this. Diff file with changes after running make devinst.ok
> is
> attached.
>
>
Ok, so at least it looks we are compatible with Windows :-)
I will check out your suggestion about using SetupDiRemoveDevice (and
maybe
SetupDiRemoveDeviceInterface) to clean up the registry.
I already found that it doesn't work on NT4 for everything as we have a
bogus
bogus entry (missing the ClassGUID value). This means you can't even
enumerate
this one and it won't be covered by the remove calls.
So what about a cleanup_before function that gets rid of everything
that's
currently bogus in the registry? If we don't do this before we have to
cater for
existing keys in every test which will clutter the tests I think. If we
really
want to test existing keys we should do so a part of a normal test.
After that cleanup_before is working we can change the tests to clean up
after
themselves.
>>> Will the new 'cleanup after' code not delete these invalid entries?
>>> One test run is fine to sacrifice for the sake of not cluttering up
>>> the tests with temporary cleanup code.
>>>
>> The problem is that we could have failures because of existing keys and we
>> have to cater for that in every test maybe.
>>
>> I agree with you though and will first check if having the 'cleanup after'
>> serves it's purpose (even if we have to run the test twice to actually see
>> results).
>>
>> Could take a while though as I have to check which tests leaves what keys
>> around. Then how I can get rid of them on every platform. Wine doesn't have
>> the SetupDiRemove stuff yet btw.
>>
>
> All I'm saying is that there shouldn't be a reason to have a hacky
> pre-cleanup. All the cleanup that is needed for the tests should be
> added, and after one round of failures, the next set of tests should
> be clean.
>
Agree
--
Cheers,
Paul.
Re: unknown device issues after running winetest
On Fri, May 23, 2008 at 3:10 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
> James Hawkins wrote:
>>
>> On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Alexander Morozov wrote:
>
> Can someone confirm that after running the devinst tests, the registry
> on
> Wine still shows these:
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> stuff below)
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> below)
>
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
> -3F65-11DB-B704-0011955C2BDB} (and stuff below)
I can confirm this. Diff file with changes after running make devinst.ok
is
attached.
>>> Ok, so at least it looks we are compatible with Windows :-)
>>>
>>> I will check out your suggestion about using SetupDiRemoveDevice (and
>>> maybe
>>> SetupDiRemoveDeviceInterface) to clean up the registry.
>>>
>>> I already found that it doesn't work on NT4 for everything as we have a
>>> bogus
>>> bogus entry (missing the ClassGUID value). This means you can't even
>>> enumerate
>>> this one and it won't be covered by the remove calls.
>>>
>>> So what about a cleanup_before function that gets rid of everything
>>> that's
>>> currently bogus in the registry? If we don't do this before we have to
>>> cater for
>>> existing keys in every test which will clutter the tests I think. If we
>>> really
>>> want to test existing keys we should do so a part of a normal test.
>>>
>>> After that cleanup_before is working we can change the tests to clean up
>>> after
>>> themselves.
>>>
>>
>> Will the new 'cleanup after' code not delete these invalid entries?
>> One test run is fine to sacrifice for the sake of not cluttering up
>> the tests with temporary cleanup code.
>>
> The problem is that we could have failures because of existing keys and we
> have to cater for that in every test maybe.
>
> I agree with you though and will first check if having the 'cleanup after'
> serves it's purpose (even if we have to run the test twice to actually see
> results).
>
> Could take a while though as I have to check which tests leaves what keys
> around. Then how I can get rid of them on every platform. Wine doesn't have
> the SetupDiRemove stuff yet btw.
>
All I'm saying is that there shouldn't be a reason to have a hacky
pre-cleanup. All the cleanup that is needed for the tests should be
added, and after one round of failures, the next set of tests should
be clean.
--
James Hawkins
Re: unknown device issues after running winetest
James Hawkins wrote:
> On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> Alexander Morozov wrote:
Can someone confirm that after running the devinst tests, the registry on
Wine still shows these:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
stuff below)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
below)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
-3F65-11DB-B704-0011955C2BDB} (and stuff below)
>>> I can confirm this. Diff file with changes after running make devinst.ok is
>>> attached.
>>>
>>>
>> Ok, so at least it looks we are compatible with Windows :-)
>>
>> I will check out your suggestion about using SetupDiRemoveDevice (and maybe
>> SetupDiRemoveDeviceInterface) to clean up the registry.
>>
>> I already found that it doesn't work on NT4 for everything as we have a bogus
>> bogus entry (missing the ClassGUID value). This means you can't even
>> enumerate
>> this one and it won't be covered by the remove calls.
>>
>> So what about a cleanup_before function that gets rid of everything that's
>> currently bogus in the registry? If we don't do this before we have to cater
>> for
>> existing keys in every test which will clutter the tests I think. If we
>> really
>> want to test existing keys we should do so a part of a normal test.
>>
>> After that cleanup_before is working we can change the tests to clean up
>> after
>> themselves.
>>
>
> Will the new 'cleanup after' code not delete these invalid entries?
> One test run is fine to sacrifice for the sake of not cluttering up
> the tests with temporary cleanup code.
>
The problem is that we could have failures because of existing keys and we have
to cater for that in every test maybe.
I agree with you though and will first check if having the 'cleanup after'
serves it's purpose (even if we have to run the test twice to actually see
results).
Could take a while though as I have to check which tests leaves what keys
around. Then how I can get rid of them on every platform. Wine doesn't have the
SetupDiRemove stuff yet btw.
--
Cheers,
Paul.
Re: unknown device issues after running winetest
On Fri, May 23, 2008 at 2:59 AM, Paul Vriens <[EMAIL PROTECTED]> wrote:
> Alexander Morozov wrote:
>>> Can someone confirm that after running the devinst tests, the registry on
>>> Wine still shows these:
>>>
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
>>> stuff below)
>>>
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
>>> below)
>>>
>>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
>>> -3F65-11DB-B704-0011955C2BDB} (and stuff below)
>>
>> I can confirm this. Diff file with changes after running make devinst.ok is
>> attached.
>>
>>
> Ok, so at least it looks we are compatible with Windows :-)
>
> I will check out your suggestion about using SetupDiRemoveDevice (and maybe
> SetupDiRemoveDeviceInterface) to clean up the registry.
>
> I already found that it doesn't work on NT4 for everything as we have a bogus
> bogus entry (missing the ClassGUID value). This means you can't even enumerate
> this one and it won't be covered by the remove calls.
>
> So what about a cleanup_before function that gets rid of everything that's
> currently bogus in the registry? If we don't do this before we have to cater
> for
> existing keys in every test which will clutter the tests I think. If we really
> want to test existing keys we should do so a part of a normal test.
>
> After that cleanup_before is working we can change the tests to clean up after
> themselves.
>
Will the new 'cleanup after' code not delete these invalid entries?
One test run is fine to sacrifice for the sake of not cluttering up
the tests with temporary cleanup code.
--
James Hawkins
Re: unknown device issues after running winetest
Alexander Morozov wrote:
>> Can someone confirm that after running the devinst tests, the registry on
>> Wine still shows these:
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
>> stuff below)
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
>> below)
>>
>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
>> -3F65-11DB-B704-0011955C2BDB} (and stuff below)
>
> I can confirm this. Diff file with changes after running make devinst.ok is
> attached.
>
>
Ok, so at least it looks we are compatible with Windows :-)
I will check out your suggestion about using SetupDiRemoveDevice (and maybe
SetupDiRemoveDeviceInterface) to clean up the registry.
I already found that it doesn't work on NT4 for everything as we have a bogus
bogus entry (missing the ClassGUID value). This means you can't even enumerate
this one and it won't be covered by the remove calls.
So what about a cleanup_before function that gets rid of everything that's
currently bogus in the registry? If we don't do this before we have to cater
for
existing keys in every test which will clutter the tests I think. If we really
want to test existing keys we should do so a part of a normal test.
After that cleanup_before is working we can change the tests to clean up after
themselves.
--
Cheers,
Paul.
Re: unknown device issues after running winetest
> Can someone confirm that after running the devinst tests, the registry on
> Wine still shows these:
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\ROOT\LEGACY_BOGUS (and
> stuff below)
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\BOGUS (and stuff
> below)
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\{6A55B5A4
>-3F65-11DB-B704-0011955C2BDB} (and stuff below)
I can confirm this. Diff file with changes after running make devinst.ok is
attached.
--- system_1.reg 2008-05-23 11:30:23 +0400
+++ system.reg 2008-05-23 11:30:50 +0400
@@ -8476,7 +8476,7 @@ WINE REGISTRY Version 2
"Common Templates"=str(2):"%ALLUSERSPROFILE%\\\x428\x430\x431\x43b\x43e\x43d\x44b"
"Favorites"=str(2):"%ALLUSERSPROFILE%\\\x418\x437\x431\x440\x430\x43d\x43d\x43e\x435"
-[Software\\Microsoft\\Windows\\CurrentVersion\\Fonts] 1211527787
+[Software\\Microsoft\\Windows\\CurrentVersion\\Fonts] 1211527847
"Andale Mono (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\andalemo.ttf"
"Arial (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\arial.ttf"
"Arial Black (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\ariblk.ttf"
@@ -10485,7 +10485,7 @@ WINE REGISTRY Version 2
"Auto"="1"
"Debugger"="winedbg --auto %ld %ld"
-[Software\\Microsoft\\Windows NT\\CurrentVersion\\Fonts] 1211527787
+[Software\\Microsoft\\Windows NT\\CurrentVersion\\Fonts] 1211527847
@=""
"Andale Mono (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\andalemo.ttf"
"Arial (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\arial.ttf"
@@ -11257,6 +11257,21 @@ WINE REGISTRY Version 2
"StemmerClass"=""
"WBreakerClass"="{369647e0-17b0-11ce-9950-00aa004bbb1f}"
+[System\\CurrentControlSet\\Control\\DeviceClasses\\{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\##?#ROOT#LEGACY_BOGUS##{6A55B5A4-3F65-11DB-B704-0011955C2BDB}] 1211527847
+"DeviceInstance"="ROOT\\LEGACY_BOGUS\\"
+
+[System\\CurrentControlSet\\Control\\DeviceClasses\\{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\##?#ROOT#LEGACY_BOGUS##{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\#] 1211527847
+"SymbolicLink"="?\\ROOT#LEGACY_BOGUS##{6A55B5A4-3F65-11DB-B704-0011955C2BDB}"
+
+[System\\CurrentControlSet\\Control\\DeviceClasses\\{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\##?#ROOT#LEGACY_BOGUS##{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\#Oogah] 1211527847
+"SymbolicLink"="?\\ROOT#LEGACY_BOGUS##{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\Oogah"
+
+[System\\CurrentControlSet\\Control\\DeviceClasses\\{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\##?#ROOT#LEGACY_BOGUS#0001#{6A55B5A4-3F65-11DB-B704-0011955C2BDB}] 1211527847
+"DeviceInstance"="ROOT\\LEGACY_BOGUS\\0001"
+
+[System\\CurrentControlSet\\Control\\DeviceClasses\\{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\##?#ROOT#LEGACY_BOGUS#0001#{6A55B5A4-3F65-11DB-B704-0011955C2BDB}\\#] 1211527847
+"SymbolicLink"="?\\ROOT#LEGACY_BOGUS#0001#{6A55B5A4-3F65-11DB-B704-0011955C2BDB}"
+
[System\\CurrentControlSet\\Control\\Nls\\Codepage] 1211527787
"37"=""
"ACP"="1252"
@@ -11664,6 +11679,15 @@ WINE REGISTRY Version 2
[System\\CurrentControlSet\\Control\\Windows] 1211527787
"CSDVersion"=dword:0400
+[System\\CurrentControlSet\\Enum\\ROOT\\LEGACY_BOGUS\\] 1211527847
+"ClassGUID"="{6A55B5A4-3F65-11DB-B704-0011955C2BDB}"
+
+[System\\CurrentControlSet\\Enum\\ROOT\\LEGACY_BOGUS\\0001] 1211527847
+"ClassGUID"="{6A55B5A4-3F65-11DB-B704-0011955C2BDB}"
+
+[System\\CurrentControlSet\\Enum\\USB\\BOGUS\\] 1211527847
+"ClassGUID"="{6A55B5A4-3F65-11DB-B704-0011955C2BDB}"
+
[System\\CurrentControlSet\\Hardware Profiles\\Current\\Software\\Fonts] 1211527787
"FIXEDFON.FON"="vgafixr.fon"
"FONTS.FON"="vgasysr.fon"
--- user_1.reg 2008-05-23 11:30:28 +0400
+++ user.reg 2008-05-23 11:30:50 +0400
@@ -360,10 +360,10 @@ WINE REGISTRY Version 2
"RelayExclude"="ntdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.94;kernel32.95;kernel32.96;kernel32.97;kernel32.98"
"RelayFromExclude"="winex11.drv;user32;gdi32;advapi32;kernel32"
-[Software\\Wine\\Fonts] 1211527787
+[Software\\Wine\\Fonts] 1211527847
"Codepages"="1251,866"
-[Software\\Wine\\Fonts\\External Fonts] 1211527787
+[Software\\Wine\\Fonts\\External Fonts] 1211527847
"Andale Mono (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\andalemo.ttf"
"Arial (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\arial.ttf"
"Arial Black (TrueType)"="Z:\\usr\\share\\fonts\\ttf\\ms\\ariblk.ttf"
