Re: [Wine] Re: Difference Between WINE and an Emulator
Scott Ritchie wrote: On Thu, 2006-12-07 at 11:59 +1000, Edward Savage wrote: An emulator is a specific type of program that mimics hardware. Windows is not a piece of hardware, ergo Wine Is Not an Emulator. It's merely a clone of the Windows API. This is probably the best answer you will get that is clear and simple. Out of interest the term I use to explain to others the concept is that WINE is a compatibility layer between Linux and Windows. Does that seem an accurate use of the word? It tends to set the right impression in the minds of the people I've explained it too. Yes. What Wine is doing is actually very similar to the way Windows XP runs programs originally made for Windows 95, and the way Vista will run programs written for Windows XP. Most people agree that Windows isn't "emulating" itself. Thanks, Scott Ritchie My alternative explanation, but might be wrong, is: "Windows has the concept of userland domain and kernel domain and the existence of an API between them. WINE simply provides this same API so that windows userland applications can run with the Linux kernel instead of the Windows kernel. WINE then goes further and provides native versions of some userland windows system .DLLs so as to minimise the amount of windows binarys required to run applications and improve performance." James
Re: direct access to IO space [Was: kernel level drivers - next try]
Saulius Krasuckas wrote: > * On Sat, 14 Oct 2006, James Courtier-Dutton wrote: >> * Rolf Kalbermatter wrote: >>> * Saulius Krasuckas [EMAIL PROTECTED] wrote: >>>> Today I have tried to compile ntoskrnl.exe, then checked out master >>>> branch, compiled stock Wine, then tried to run win32 app which do >>>> simple port I/O after it loads (GIVE)IO.SYS driver. Driver simply >>>> loaded, did its initialization and immediatelly exited. >>> ... >>> I'm not positive these can all be easily added to a process operating >>> in user space without some specific kernel support for this >>> functionality and in fact allowing full IO access to a user space >>> application such as Wine just doesn't seem safe to me. > ... >> Why do we need to give an application direct access to IO space? > > Imagine some new motherboard model with uniq internal debugging device. > And its supporting software designed only for Win32 platforms. Or imagine > some proprietary portable music player connected via LPT and using its own > protocol. User wants to make them work on linux. Just that's why. > > I see two reports in out bugzilla on this topic: [6], [7]. > > IMHO, we don't need to give this access to all of applications. We just > need a way to redirect operation from a particular win32 app to small > piece of "raw-io-unrestricted" code. > > > [6] http://bugs.winehq.org/show_bug.cgi?id=3358#c6 > [7] http://bugs.winehq.org/show_bug.cgi?id=3836#c8 > This feature is being ask for by people who don't understand what most hardware requires from a "driver". 1) IO ports or memory mapped IO. 2) DMA handler 3) IRQ handler Getting IO port access in wine really is not going to help a whole lot! James
Re: kernel level drivers - next try
Rolf Kalbermatter wrote: > Saulius Krasuckas [EMAIL PROTECTED] wrote: > >> Today I have tried to compile ntoskrnl.exe, then checked out master >> branch, compiled stock Wine, then tried to run win32 app which do simple >> port I/O after it loads (GIVE)IO.SYS driver. Driver simply loaded, did >> its initialization and immediatelly exited. > > The IO sys driver I have worked with and made myself in the past > > http://opengtoolkit.cvs.sourceforge.net/opengtoolkit/portIO/c_source/ > > (The whole opengtoolkit project is really related to a software called LabVIEW > and this was a driver to give direct IO access to it, but the portio kernel > driver and its user space DLL can be used from any application that can call > DLLs). > > did use a number of specific kernel functions such as > > NTKERNELAPI void Ke386SetIoAccessMap(int, IOPM *); > NTKERNELAPI void Ke386QueryIoAccessMap(int, IOPM *); > NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS, int); > NTKERNELAPI NTSTATUS PsLookupProcessByProcessId(IN ULONG ulProcId, OUT > PEPROCESS * pEProcess); > > which all were and maybe still are considered undocumented. These are for > manipulating the IO permission map so that applications can directly use the > inp and outp opcode in application space for enabled IO adresses. > > Alternatively it can access IO ports through a kernel driver call using a > combination > of: > > HalTranslateBusAddress > MmMapIoSpace > > So all these functions together with several more for standard kernel driver > interaction with the system need to be exported by the subsystem that loads > them (eg. ntoskrnl.exe or its helpers like hal.dll etc). > > I'm not positive these can all be easily added to a process operating in user > space > without some specific kernel support for this functionality and in fact > allowing > full IO access to a user space application such as Wine just doesn't seem safe > to me. > > Especially the first method while being a bit faster for standard IO access is > probably a real trouble to implement. I have not found a way to manipulate the > Linux IO permission map without a specific kernel extension and don't think > such > an extension would ever make it in the mainstream kernel. > > Rolf Kalbermatter > Why do we need to give an application direct access to IO space?
Re: Copy protection
Tim Schmidt wrote: On 10/6/06, Kai Blin <[EMAIL PROTECTED]> wrote: On Friday 06 October 2006 10:19, Tim Schmidt wrote: > Again, works for me. I believe the only part missing for this case is > the simulation. Of course, there's the added possibility that apps > will go mucking about with data other apps care about, in which case a > per-executable simulated device would be best. Wouldn't that break on Windows, too? If I have have two apps that muck about in my mbr, I expect them both to work, so they better do whatever they do in a sane way. I don't see how this would be different for a simulated drive. Yeah. you're right. I just don't trust every app that mucks about with the MBR to be courteous and correct ;) --tim Messing with the MBR might be the windows way, but last time I looked, even windows apps cannot access the HD directly. In Linux, any access by a user app to the MBR should never happen, except maybe by cfdisk,lilo grub and friends. Certainly NOT a wine application. No one in their right mind would run wine as root, knowing how many viruses windows has. I would suggest that these applications are not actually writing to the MBR, but instead there is a bug in wine causing it to happen. The only way to fix this whole MBR issue, is to find an application with copy protection, and actually get it to work. We will then have 100% accurate data regarding what feature we would actually need in wine to allow these copy protected applications to be compatible with wine. End the speculation. James
Re: Copy protection
Martin Owens wrote: Re Copy Protection. be quite hard to make this work I think? It would be quite dangerous to make this work. What about creating a file say with a fake data map, wine thinks it's the direct access to the hard drive where all this information is held. all we do is add the place where the data starts and the data thats stored. it would be slower but it would get around the dangers while keeping the interface the same. The easiest way round this is to simply recognise the executable with the copy protection, and simply install a hook to catch the appropriate file system or registry calls and divert them to a special handling routine to satisfy the application. The difficulty would come from actually implementing the "copy protection" part. I.e. Preventing the wine user from copying the software. James
Re: my dsound/winealsa hacks
Tomas Carnecky wrote: James Courtier-Dutton wrote: I have place some documentation on the ALSA wiki site: https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=ALSAresampler It tries to explain the constraints that the current ALSA resampler works under. You might like to read it as I think it will have impact on your plans. Thanks. One question though, if the app in in blocking mode and requests the said two periods, will alsa wait until the hardware has processed three 48000Hz-periods and then copy the two 44100Hz-periods to the application (because: 3 periods at 48000Hz > 2*1024 frames at 44100Hz)? DirectSound doesn't know anything about periods, the windows application operates on bytes rather than frames or periods. So whether I'd have to wait for two or three periods wouldn't matter. The important thing is that I get X bytes in the right format to pass that back to the application. tom Maybe the ALSA terminology needs to be clarified. A frame is equivalent of one sample being played, irrespective of the number of channels or the about of bits. e.g. 1 frame of a Stereo 48khz 16bit PCM stream is 4 bytes. 1 frame of a 5.1 48khz 16bit PCM stream is 12 bytes. A period is the amount of frames in between each hardware interrupt. The poll() will return once a period. The buffer is a ring buffer. The buffer size always has to be greater than one period size. Commonly this is 2*period size, but some hardware can do 8 periods per buffer. It is also possible for the buffer size to not be an integer multiple of the period size. Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. The application 44100Hz will also have 2 periods of 940 frames. ALSA will endeavor to keep the buffer as full as possible. Once the first period has been played, the third is transfered into the space the first one occupied while the second period is being played. (normal ring buffer behaviour). So, once a period has been transfered to the sound card hardware, it cannot be modified, even though the sound card has not yet played it from the DACs. As Direct Sound does not know anything about periods, I don't really know how you will be able to get it to work well with ALSA. I expect that some sort of double buffer will be required. Does Direct Sound have a concept of position of the ADC, and also a concept of where in the buffer it is sensible to fill with new samples? James
Re: my dsound/winealsa hacks
Tomas Carnecky wrote: My ultimate goal was to solve the dsound underruns which were so horrible that I had to disable sound in World of Warcraft. While I managed to get the sound working flawlessly (really... I never heard such clear sound under wine) in WoW, it required WoW-specific hacks so my patch will never make it (in its current form) into the official git tree, but maybe someone can use some of my ideas to improve dsound/winealsa. The basic idea is to let alsa mix the sound instead of the infamous dsound mixer. The advantage is that if the hardware supports mixing, there is very little overhead, if not, there's still dmix which can do that, but dsound doesn't need to care how it's done, it's entirely up to alsa. I have place some documentation on the ALSA wiki site: https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=ALSAresampler It tries to explain the constraints that the current ALSA resampler works under. You might like to read it as I think it will have impact on your plans. James
Re: my dsound/winealsa hacks
Tomas Carnecky wrote: My ultimate goal was to solve the dsound underruns which were so horrible that I had to disable sound in World of Warcraft. While I managed to get the sound working flawlessly (really... I never heard such clear sound under wine) in WoW, it required WoW-specific hacks so my patch will never make it (in its current form) into the official git tree, but maybe someone can use some of my ideas to improve dsound/winealsa. The basic idea is to let alsa mix the sound instead of the infamous dsound mixer. The advantage is that if the hardware supports mixing, there is very little overhead, if not, there's still dmix which can do that, but dsound doesn't need to care how it's done, it's entirely up to alsa. I have placed some documentation on the ALSA wiki site: https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=ALSAresampler It tries to explain the constraints that the current ALSA resampler works under. You might like to read it as I think it will have impact on your plans. James
Re: ALSA implementation
Molle Bestefich wrote: James Courtier-Dutton wrote: I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate. alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib. What are the constraints? In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon. Seems to me that it would take less development resources to fix an existing resampling implementation with known restraints, than to code a new one. Also it would end up helping more people. If someone from the Wine community wants to fix the existing ALSA resampler, what needs to be done? As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling. What sound API is used on Mac OS X? Does that API require Wine to do resampling, or do things work OOTB there? The possible so called "fix" is still a long way off. It requires a lot of work. As there are only a few alsa developers, that means it will take a long time. We each have rather long TODO lists currently and would welcome any offer to help ALSA development. Resampling is not a simple problem to fix. The technically best solution is for the application to do the resampling before passing it to the sound card, so any effort to do it in the sound drivers is always going to be sub-optimal, with sound quality suffering. The current alsa method achieves resampling with minimal effort, but presents some constraints to the application. These "constraints" are only a problem for closed source applications. In order to reduce the "constraints" so that ALSA works better with wine will result in trade offs. I.e. better compatibility with binary only application, but increased sound latency due to the required extra double buffers. I will document the "constraints" when I get a moment. James
Re: ALSA implementation
Jan Zerebecki wrote: On Mon, Sep 18, 2006 at 01:54:26AM -0400, Aaron Slunt wrote: Jan, could you please clarify what you mean by an fd-based method? Thanks. On http://alsa-project.org/alsa-doc/alsa-lib/pcm.html search for the headline "Event waiting routines". That is what I meant with fd-based method. Below that is "Asynchronous notification" and it describes what we currently use in winealsa. Jan I don't think asynchronous notification works at all well. There are several polling methods that can be used. 1) block on poll Used in jackd and generally considered the best method currently. It is often called the "callback" method where one has a thread block on the poll, and then call the "callback" function when triggered. jackd expands on this idea letting multiple different applications "callback" functions be called per trigger event. 2) let the audio buffer free wheel and use a timer to periodically fill/drain the buffers. (what ex windows apps/games tend to do. E.g. Doom3.) The current asynchronous method uses signals and as a result does not tend to work at all well. James
Re: ALSA implementation
Aaron Slunt wrote: Jan Zerebecki wrote: On Sun, Sep 17, 2006 at 05:26:12PM +0100, James Courtier-Dutton wrote: I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start. Everything in wine that uses alsa is below dlls/winmm/winealsa/. I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html ) I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together. As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. We just need someone to code this change. It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works. Jan Jan, could you please clarify what you mean by an fd-based method? Thanks. I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate. If a windows application wants 44.1kHz, I would suggest that you add your own resampling code to wine. The reason for this is that a Linux application can ask for some buffer size from the alsa-lib. If the sound card hardware cannot do that buffer size in hardware, alsa-lib will reject the request and leave it to the application to try a different value. This is all ok for an open source application, as one can just fix the application to act accordingly. This is not the case with a binary application like all the applications running on top of wine. One cannot fix those applications to work nicely with alsa-lib. As a majority of sound card hardware works nicely at 48kHz, but very few sound cards do 44.1kHz in hardware, the application must then do the resampling necessary to achieve the task. alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib. In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon. As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling. James
Re: ALSA implementation
Aaron Slunt wrote: Hi, I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well. My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly? Thanks. I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start. I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together. James
Problem with a Turbolog4.exe application under wine
Hi, A demo version of Turbolog4 can be downloaded from: http://www.turbolog.de/ The program installs ok, but fails to run correctly. It asks for a License key, one should be able to press cancel and bypass it into demo mode where a window is displayed for entering log records. Can anyone help be diagnose why it fails. James
GoogleEarth
Hi, Can one run GoogleEarth under wine? It does not seem to run here under the default settings. James
Re: Implement DVD_ReadStructure
Detlef Riekenberg wrote: Am Sonntag, den 05.02.2006, 22:01 +1100 schrieb Troy Rollo: ChangeLog: Implement DVD_ReadStructure --- /dev/null 2006-02-03 18:20:42.451563144 +1100 +++ wine-git/include/ntddcdvd.h 2006-02-05 21:50:39.0 +1100 Please use "include/ddk/" As a side note. Has anyone worked out how Windows creates the unique DVD ID? James
Re: Implement DVD_ReadStructure
Detlef Riekenberg wrote: Am Sonntag, den 05.02.2006, 22:01 +1100 schrieb Troy Rollo: ChangeLog: Implement DVD_ReadStructure --- /dev/null 2006-02-03 18:20:42.451563144 +1100 +++ wine-git/include/ntddcdvd.h 2006-02-05 21:50:39.0 +1100 Please use "include/ddk/" As a side note. Has anyone worked out how Windows creates the unique DVD ID? James
Re: Wine passes WGA test
Francois Gouget wrote: On Fri, 5 Aug 2005, Ivan Leo Puoti wrote: [...] Also the anti wine checks appear to be disabled as the tool works in both windows 2000 and windows 98 mode, however the wine registry key string is still in the binary, maybe it's just disabled. IIRC it's checking the location of the old Wine config registry key. This has all moved as part of the config file removal (and as was planned long before WPA came around). No doubt they will update their WPA checks at some point... Would it be wiser to implement a wine feature to block a particular application from seeing a particular registry key. We could then only allow the key to be visable to the application it would actually be useful for. I think the MS windows registry already has this feature in order to provide security for certain registry entries. James
Re: Wine device drivers proposal
Damjan Jovanovic wrote: > Hi > > I've been trying to add STI (still image) support to > Wine, and I've made some progress. However, I see a > deep and unsurmountable need to add (at least > user-space) device drivers to Wine, and I would like > some feedback on these ideas. > > Basically, many Windows device drivers are really > trivial, but required for many apps. A scanner driver > typically just accepts commands from a user-space app, > does minimal processing, and forwards that to Windows. > I've already hacked up Wine to get the same > functionality, and it works - partially. > > I propose adding a driver loading system to Wine that > works as follows: > -CreateFile() gets a device filename, like (in my > case) \\.\MiiScan0 > -Currently, Wine's behaviour for such a filename is to > try load a VXD. > -In the case of VXD loading failure, a search is > performed in (Wine's) C:\Windows\System32\Drivers (or > somewhere else?) for a matching driver. > > The driver is then loaded and used for (at least): > ReadFile() > WriteFile() > DeviceIoControl() > CloseHandle() > > The problem is, how is a handle mapped to the > appropriate driver? I've thought about it, and come up > with 3 solutions. The first 3 don't require changes to > the wineserver but aren't pretty. > > 1. Make the driver a true Linux kernel mode driver, > and the handle its device file handle. Since > ReadFile() and WriteFile() just do read() and write() > system calls, this can be done. The problem is, > DeviceIoControl() has to be implemented using ioctl(), > and that's dangerous (sending the right codes to the > wrong device can be catastrophic). Also, it's not > portable to other OS's, and requires writing a kernel > module (which isn't fun). > > 2. The driver is a file giving a process to start and > some IPC method to use. Wine starts the process and > uses the IPC method to communicate with the driver. > This is good as far as Wine's current ReadFile() and > WriteFile() go, since they don't have to know they're > not writing to an actual file. The problem here is, > which IPC method supports both read() and write() on > the same file descriptor, preserves message > boundaries, and carries out-of-band data for > DeviceIoControl()? I was thinking TCP sockets, but > they don't preserve message boundaries. > > 3. KERNEL32.DLL and / or NTDLL.DLL keep their own > handle table so they know which handles are driver > handles and deal with those appropriately. Having to > look up these tables for every call to ReadFile(), > WriteFile() and DeviceIoControl() might be very > inefficient, though. > > 4. Use an in-process solution, like a winelib DLL that > has exports for dealing with ReadFile(), WriteFile() > and DeviceIoControl(). This could be the most > efficient, but then again, you need an efficient way > to test a handle for being a driver handle, find the > appropriate driver, and call the right exported > function, which likely means the wineserver needs to > have knowledge of these drivers and provide > functionality for testing a handle for being a driver > handle and have a way to find the driver. > > Let me know what you think. > > Bye > Damjan > I would like this but mainly for a different reason. I help reverse engineer hardware so that we can write linux drivers for it. This reverse engineering task would be easier if I could install the windows drivers on my linux box and run them, and then watch their activity with the hardware. For this to work, we would have to implement the HAL.DLL in wine, a small kernel module for it to communicate with and probably a few other bits. This would greatly help the hardware reverse engineering requirements in order to get hardware to interoperate with Linux. Currently, I have to installed special .DLLs on a windows box and perform the logging there. I would much prefer to do it all on Linux. The side effect of this would be that wine will support some hardware even before Linux gets support for it. This "kernel module" would only be run for the reverse engineering task, as it would most likely make the linux kernel very insecure. Any comments James
Re: Regression in winealsa (message only?)
Jeremy White wrote: > Hi Paul, > > I see the same behavior after Robert's change to use plug:hw:0 > (and removing my settings in ~/.wine/config). > > The attached patch 'fixes' the problem for me; can you try it? > > However, to be honest, the real issue is that I don't really > understand what's going on. It appears as though the > plug: devices are legitimate PCM device names, but that you > can't use them for the control interface. If that's true, > then this patch is correct. I just can't find any sensible > Alsa document to give me comfort that this is right. > > I'd appreciate affirmation of this or a pointer to better > Alsa doco . > > Cheers, > > Jeremy > I am an alsa developer, what exactly is the problem? For normal stereo playback use: "plug:front" For 5.1 playback use: "plug:surround51" For stereo capture (record) use: "plug:front" For mixer control interface use: "hw" The alsa api is an abstraction layer. One defines in an alsa config file what "plug:front" actually talks to. Then any alsa applications can then talk to same device name, even though the underlying hardware might have different features. As a generaly rule, don't use "hw" anywhere in the sound channel's device name. If you have more than one sound card, things are a bit different: First card: Stereo playback: "plug:front:0" surround51 playback: "plug:surround51:0" Stereo capture: "plug:front:0" Mixer: "hw:0" For second card: Stereo playback: "plug:front:1" surround51 playback: "plug:surround51:1" Stereo capture: "plug:front:1" Mixer: "hw:1" For third card: Stereo playback: "plug:front:2" surround51 playback: "plug:surround51:2" Stereo capture: "plug:front:2" Mixer: "hw:2" etc. Now the user might want to edit their alsa config files, so ideally wine should allow for multiple device names to be entered for each card.
Re: Support for IDvdInfo2::GetDiscID
Tim Hentenaar wrote: On Sat, 19 Jun 2004 14:42:27 +0100 James Courtier-Dutton <[EMAIL PROTECTED]> wrote: The Windows api method uses the function call IDvdInfo2::GetDiscID http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/idvdinfo2getdiscid.asp This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method. If no-one else has figured it out yet, I might try my hand at reverse engineering it just for the hell of it. :P Tim Did you make any progress on this?
Re: Problems installing IE6
Joaquín Fernández wrote: Stefan Leichter wrote: Am Montag, 27. September 2004 20:03 schrieb Joaquín Fernández: Hello, try WINEDLLOVERRIDES="advapi32=builtin" (see http://www.winehq.org/hypermail/wine-devel/2004/08/0640.html) Bye Stefan Thanks Stefan, i tried but i can't install IE, the installer stay in endless loop at the end of process. I tried with other WINEDLLOVERRIDES but i was not able to install IE. Regards Joaquín Is WINEDLLOVERRIDES pronounced "Wined Lover Rides" ? ;-)
MS Project 2000 not working in wine.
Has anyone got MS Project 2000 working in wine? James
MS Visio 2000 not working with wine.
Has anyone got MS Visio 2000 working with wine? James
Support for IDvdInfo2::GetDiscID
The Windows api method uses the function call IDvdInfo2::GetDiscID http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/idvdinfo2getdiscid.asp This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method. Cheers James
Re: General serial communications issues
Raul Dias wrote: Hi, I have problems with wine serial code since 2000/2001. I think this might be related to your problem. In my situation, I have a bunch of stores that runs linux. Their sales sistem is remote application that can be run thru ssh/telnet/... Unfortunally they are required to use expensive serial fiscal printers that does not work with linux. The solution was to use netterm, a freeware term program, that given special escape sequences, it will handle it to a proprietary dll that them comunicates to the printer driver. Everything worked fine until the serial rewrite somewhere between 2000 and 2001. One strange thing is that some new printers (different brand) now works fine with wine, while the older printer does not. I can only get them to work with wine 20001026. So you probably should try that out if you have a chance. One problem is that this is a really old version of wine, which makes it really difficult to compile under a new distro with gcc 3.x, new glibc and probably kernel 2.6. I am not a serial expert, but I don't understand what can change in the serial communication to work with one printer and not work with another (that use to work). For me serial is TX, RX and a few control pins and that's it. Does anyone knows what really changed in the serial code? Should the new code works like the old one or is there fundamental differences that makes this incompatible? Could this be a API problem and not a problem in the way serial is handled? I have the same application with both wines. Old 20001026 (in a old distro) for the old printer and recent builds (in fresh distro) for the new printer in different machines. Is there any debugging code I can generate to help solve or find where the problem lies? I really would like to help solve this issue, however I have little win32 knowledge. []'s Raul Dias The serial port problem has now been fixed. It is not in the CVS yet, but the patches attached to previous emails in this thread, when applied to the current CVS, make serial comms work. I hope this gets all your "serial fiscal printers" working with the latest wine versions. Althought the serial comms now works, it might not work with the redirector your were using. Maybe you won't need the redirector any more. Cheers James
Re: General serial communications issues
Eric Pouech wrote: Izak Burger a écrit : Hello, Perhaps I should appologise, I have been lurking on the list way too long and this message just passed by while I was messing arround with the next project, which gladly does not involve serial comms and wine :-) does this fix it ? A+ This works for me also. Nice work. Cheers James
Microsoft Visio 2000
Has anyone managed to get Microsoft Visio 2000 working on a native wine install. I.E. No Pre installed Windows partition. If so, how? If not, I will open a bug and post the details of where the install fails. Cheers James
Re: General serial communications issues
Eric Pouech wrote: The next time the app calls read, wine sets off a new (now making it two) FILE_AsyncReadService, but clears the buffer first, so all the characters received from the previous FILE_AsyncReadService get lost. it seems the event to be signaled when something is done in the first read is never set, hence the application not reading the content of the buffer. can you send me the trace generated with the latest patch ? A+ I attach 2 log files. One is the latest wine cvs (before) The other is after applying your comm.diff patch (after) The setup now is: - 2 PCs. With serial link between them Log taken with this command: On PC 1: WINEDEBUG="+comm,+file,+ntdll" wine ttermpro.exe 2>after-patch.txt On PC 2: kermit kermit is a native linux app. I type "test1" then press ENTER on the kermit terminal, so 6 chars sent. Nothing appears on the destination terminal, although you can see the chars hitting wine. No chars are reaching the windows app. trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 1/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 2/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 3/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 4/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 5/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 6/1024 so far I think that the results are almost identical, with and without your patch. I think the problem is more due to wine/dlls/kernel/file.c:339 function ReadFile() and wine/dlls/ntdll/file.c:399 function NtReadFile() With it calling at wine/dlls/ntdll/file.c:442 if (!(ovp = RtlAllocateHeap(GetProcessHeap(), 0, sizeof(async_fileio I think that it should only call this once the first time NtReadFile() is called, and then just remember it for future read calls. And also setting io_status->Information = 0; in too many places. io_status->Information should be set to 0 initially, and then let FILE_AsyncReadService() increase it when chars are received. Then, only let the NtReadFile() set io_status->Information=0; when it actually sends the chars to the application. If NtReadFile() is called with io_status->Information > 0, i.e. some chars have arrived, it should return those chars to the application. Instead it is just setting io_status->Information=0; which effectively gets it to forget all the chars that FILE_AsyncReadService() has buffered up. So, I think that we should some how store the ovp details in the file handle structure, so that it is remembered in between NtReadFile calls. If you can give me some pointers as to how best to remember the ovp state between NtReadFile calls, I could do some more tests. Well, that is my diagnosis of the problem, you might have other ideas. Cheers James comm-diff-logs.tar.bz2 Description: Binary data
Re: General serial communications issues
I have looked into the wine code now, and async reads from the COM port are just broken. The app calls read, wine sets off the FILE_AsyncReadService, and then returns to the app. FILE_AsyncReadService is called each time a character is received from the COM port, and it buffers up the received characters in the 1024 bytes buffer. The next time the app calls read, wine sets off a new (now making it two) FILE_AsyncReadService, but clears the buffer first, so all the characters received from the previous FILE_AsyncReadService get lost. This is where the input characters are getting lost. James
Re: Using objdump
Christian Costa wrote: James Courtier-Dutton wrote: I have used objdump in the past to disassemble and check the code that is generated in a .so or .o file. How do I modify objdump so I can get it do the same with win32 .exe and .dll files ? objdump already works with PE executables. Bye, Christian So it does. :-) Just need .sys files supported now. :-) Cheers James
Re: General serial communications issues
Eric Pouech wrote: So, WINE should be "return immediately with the characters that have already been received, even if no characters have been received." does this help ? A+ Yes and no. The read call does return quicker, but no actual characters get to the application if it returns quickly. characters still only get returned if I type 1024 chars. Summary: - I just have to type quicker than before! Not being able to leave much space in between chars now. ;-) Cheers James
Re: General serial communications issues
Eric Pouech wrote: James Courtier-Dutton a écrit : I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA. In addition, ttermpro.exe is setting the following: - memset(&ctmo,0,sizeof(ctmo)); ctmo.ReadIntervalTimeout = MAXDWORD; ctmo.WriteTotalTimeoutConstant = 500; SetCommTimeouts(cv->ComID,&ctmo); Which according to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/commtimeouts_str.asp Means: - ReadIntervalTimeout: Maximum time allowed to elapse between the arrival of two characters on the communications line, in milliseconds. During a ReadFile operation, the time period begins when the first character is received. If the interval between the arrival of any two characters exceeds this amount, the ReadFile operation is completed and any buffered data is returned. A value of zero indicates that interval time-outs are not used. A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the characters that have already been received, even if no characters have been received. So, WINE should be "return immediately with the characters that have already been received, even if no characters have been received." WINE is obviously not doing this. Cheers James
Using objdump
I have used objdump in the past to disassemble and check the code that is generated in a .so or .o file. How do I modify objdump so I can get it do the same with win32 .exe and .dll files ? Cheers James
Re: General serial communications issues
Eric Pouech wrote: James Courtier-Dutton a écrit : I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA. In addition to my last response regarding the 1024 buffer threshold, this web page might help. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/commtimeouts_str.asp Look at the details regarding the "ReadIntervalTimeout". Cheers James
Re: General serial communications issues
Eric Pouech wrote: James Courtier-Dutton a écrit : I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA. I linked two computers together. ttermpro on one, and kermit on the other. When I type characters on the ttermpro console, each character appears on the kermit console immeadiately. After looking at the first log: comm-file-ntdll.txt I noticed messages like this: - trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 1/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 2/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 3/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 4/1024 so far I then thought. What would happen if I typed 1024 characters. So, in the second log file I do that: comm-file-ntdll-2.txt Eventually, after typing 1024 characters, they actually arrive on the ttermpro console. Summary: - All characters are getting through the comms link, except that on the receive (READ) path, individual chars are getting buffered, and only when the buffer is full do they reach the application. This sounds to me like some Nagle algorithm gone wrong. We would want this buffering to happen if there was a lot of traffic (e.g. PPP internet link), as it would reduce the amount of api calls, but for simple interactive terminal session, if a new char has not arrived within 2 or 3 chars periods at the current baud rate, the buffer should be forwarded to the application. I attach two log files, one where I type a few characters, and one where I typed more than 1024. I hope this helps Can other people verify my findings regarding the 1024 char threshold? Cheers James comms-problems.tar.bz2 Description: Binary data
Re: General serial communications issues
David Purucker wrote: Hello, I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem. They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115 By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong. I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak. I look forward to hearing any ideas, work-arounds, or patches. Thanks I can confirm this problem. My setup is this. PC -> Serial Cable -> Loopback plug. linux based kermit works correctly, and the loopback also loops RTS/CTS. I type a character, and the loopback plug returns it back to the PC. With the loopback plug removed, no character is returned. It I then use teraterm, teraterm manages to output characters to the cable (I see LEDs flashing on the loopback plug). But, no characters make it back to windows. I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe "no-loop.txt" is without a loopback plug. "loop.txt" is with a loopback plug. So, this is certainly a wine bug, and I hope the logs help someone fix this. Cheers James fixme:comm:SetupComm insize 8192 outsize 2048 unimplemented stub trace:comm:PurgeComm handle 0x68, flags f trace:comm:SetCommTimeouts (0x68,0x406cf558) trace:comm:SetCommState handle 0x68, ptr 0x406cf56c trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState fOutxCtsFlow 0 fRtsControl 1 trace:comm:SetCommState fOutxDsrFlow 0 fDtrControl1 trace:comm:SetCommMask handle 0x68, mask 0 trace:comm:SetCommMask handle 0x68, mask 1 trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:PurgeComm handle 0x68, flags f trace:comm:EscapeCommFunction handle 0x68, function=6 trace:comm:EscapeCommFunction CLRDTR trace:comm:SetCommMask handle 0x68, mask 0 fixme:comm:SetupComm insize 8192 outsize 2048 unimplemented stub trace:comm:PurgeComm handle 0x68, flags f trace:comm:SetCommTimeouts (0x68,0x406cf558) trace:comm:SetCommState handle 0x68, ptr 0x406cf56c trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState fOutxCtsFlow 0 fRtsControl 1 trace:comm:SetCommState fOutxDsrFlow 0 fDtrControl1 trace:comm:SetCommMask handle 0x68, mask 0 trace:comm:SetCommMask handle 0x68, mask 1 trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError
Re: symbol hiding
Erik de Castro Lopo wrote: On Fri, 14 May 2004 14:24:51 +0100 James Courtier-Dutton <[EMAIL PROTECTED]> wrote: What is wrong with seeing names of internal interfaces? The main problem is the likelihood of symbol collisions between internal symbols which are the same in two different libraries. By restricting the exported symbols to just the public interfaces you reduce the chances of this. I would really like the linux program loader to at least warn us when duplicate symbols are being used. But currently, all we get is some strangely performing application with a very hard to track down bug. If someone wants to use a lib you publish, they just look in the .h file to find out how to interface with it. They won't be looking in the binary file to find out how to use it. I expect that one of the reasons why one can't control "such basic things in the ELF world" Controlling which symbols are exported from a lib is just as easy with ELF as it is in windows. I do it with both of my two libraries: I know that, I write libs for the open source community. I think what this person was saying is from the point of view of looking at the binary file itself. But even after filtering the symbols, they will then not be published externally, but can still be listed if one views the binary directly. http://www.mega-nerd.com/libsndfile/ http://www.mega-nerd.com/SRC/ Exported symbols are limited on Linux, MacOSX and Win32. Erik
Re: symbol hiding
Dmitry Timoshkov wrote: Also, I personally feel a bit not comfortable when someone (for any reason) is looking into a binary and sees names of internal interfaces not appropriate for external learn/use. I find it ugly that I can't fully control such basic things in the ELF world. What is wrong with seeing names of internal interfaces? If someone wants to use a lib you publish, they just look in the .h file to find out how to interface with it. They won't be looking in the binary file to find out how to use it. I expect that one of the reasons why one can't control "such basic things in the ELF world" is that no-one has really asked for that feature yet. Most software in the linux world is open source, so why would anyone ever want to hide stuff? If you don't want to port your application to the open source world, then, probably the best thing for you to do would be to make sure that your MS Windows application runs well in wine. Wine does not support all MS Windows features yet, and some it does support are slow. So, if you just check that your program does not use any of the un-implemented win32 functions, your application should work well. If you have to use some win32 feature not yet implemented in wine, then you might have to implement it in wine and submit a patch to wine. There are some well know applications out there that work on both windows and linux natively. E.g. The game Quake. They have never complained about the .ELF format. Cheers James
Re: Alsa compilation error
Francois Gouget wrote: On Thu, 13 May 2004, James Courtier-Dutton wrote: [...] You have to use a version of alsa that came out after 19th June 2002 I.E. 0.9.0rc2 or above. The version of alsa you are using came out in 26th Feb 2002 Just upgrade your alsa version to a NON-BETA version. Debian stable does not have anything more recent you insensitive clod! (I hope you read the Slashdot polls, otherzise ignore the last 3 words) Would restoring the macros be an acceptable way to restore compatibility with older Alsa versions? So you are using wine cvs and expecting it to work with some other code that is over 2 years old. I don't think I am the "clod" here. ;-) Just use alsa's oss emulation until you decide to upgrade your kernel.
Re: Alsa compilation error
Francois Gouget wrote: revision 1.42 date: 2004/05/05 22:03:48; author: julliard; state: Exp; lines: +143 -67 James Courtier-Dutton <[EMAIL PROTECTED]> Updated to the new alsa api. This patch causes a compilation error on my build machine: alsa-headers 0.9+0beta12-3 gcc -c -I. -I. -I../../../include -I../../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o audio.o audio.c audio.c: In function `ALSA_TraceParameters': audio.c:398: too many arguments to function `snd_pcm_hw_params_get_access' audio.c:399: too many arguments to function `snd_pcm_hw_params_get_format' audio.c:448: too many arguments to function `snd_pcm_hw_params_get_channels' audio.c:452: too many arguments to function `snd_pcm_hw_params_get_channels_min' audio.c:453: too many arguments to function `snd_pcm_hw_params_get_channels_max' audio.c:462: too many arguments to function `snd_pcm_hw_params_get_buffer_size' audio.c:466: too many arguments to function `snd_pcm_hw_params_get_buffer_size_min' It looks like it removed compatibility macros. Why? You have to use a version of alsa that came out after 19th June 2002 I.E. 0.9.0rc2 or above. The version of alsa you are using came out in 26th Feb 2002 Just upgrade your alsa version to a NON-BETA version. Cheers James
Running "United Devices Agent"
It is about time that grid.org project used open source code for their "United Devices" agent. The performance would be much greater if more people saw the source code, and helped optimise it. My $0.02 worth. James
Re: [PATCH] Updates the wine alsa driver to the new alsa api. No functionallity changes.
Roderick Colenbrander wrote: If you plan to rewrite parts of winmm/dsound it might be better to do it like Win2k/WinXP do it using "kmixer". This seems to be a redesign of the whole windows sound stuff. regards, Roderick Where are docs on "kmixer". I don't use WinXP etc. Cheers James
Re: [PATCH] Updates the wine alsa driver to the new alsa api. No functionallity changes.
Mike Hearn wrote: On Wed, 05 May 2004 14:21:06 +, James Courtier-Dutton wrote: Is there any chance of getting my patch into cvs. I could then start making further improvements to the winealsa driver. It's in CVS now. If you want to work without waiting for AJ to commit, use the arch repository. It lets you commit to your own local branch and has a script for generating and sending patch emails in a simple manner. http://navi.cx/~mike/wine/ thanks -mike Thank you. I have been working on improving wine support for alsa, but have run into some problems. Windows sound api is so incredibly bad. :-( I might just work on getting DirectSound working, and the get winmm to use direct sound instead of winmm using the sound card directly. We need to get to a single API between sound hardware and windows apis. I think winmm should work over directsound ok. I just need to look into what ASIO does now. We might end up doing winmm over directsound over asio! Cheers James
[PATCH] Updates the wine alsa driver to the new alsa api. No functionallity changes.
Is there any chance of getting my patch into cvs. I could then start making further improvements to the winealsa driver. Currently, the winealsa driver does a lot of stuff it should not, and I will changing things to make it more reliable with a wider variety of sound cards. If my patch is not going into CVS, I will not proceed with improvements over that. Cheers James P.S. Patch was posted with same subject line to the wine-patches list a few days ago.
