Re: MSDOS Error Table Handling
On Thu, 3 Jan 2002 [EMAIL PROTECTED] wrote: -/* We will use a snippet of real mode code that calls */ + /* We use a snippet of real mode code that calls */ /* a WINE-only interrupt to handle moving the requested */ - /* message into the buffer... */ +/* message into the buffer... ... - INT (WINE-only interrupt) If that's what you need, I suggest allocating a DPMI Real-Mode Callback thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use it in dosaspi.c... you give it a Wine-implemented function, and it returns a real-mode address that DOS apps can use to call it... the only thing to keep in mind is that it's the Wine function's responsibility to pop the real-mode stack)
Re: [RFC] cleaner FD_TYPE_XXX implementation
On Fri, 4 Jan 2002, Mike McCormack wrote: looks good to me. The only complication i can see is if overlapped operations are possible on consoles. Yes, but the OVERLAPPED flag must be set explicitly by the get_file_info() method of the corresponding server object. console_get_file_info() will simply leave this flag unset if overlapped operations are impossible on consoles. The idea is that get_file_info() has a more flexible way to communicate the capabilities of a file descriptor; this doesn't imply all fields are completely independent of each other. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [RFC] cleaner FD_TYPE_XXX implementation
Hi Martin, Sorry, i should have been a little more clear: if there is a overlapped console, the code in ReadFile (ie. the implemention) will ignore the fact that it is a console, and treat it as a standard overlapped file. In other words, ReadFile should check if the fd is a console fd first, then check if it has the overlapped flag. What you're trying to do is good, and my complaint is just a quibble since the console code doesn't support overlapped operations now anyway :-] Mike Original message from: Martin Wilck [EMAIL PROTECTED] On Fri, 4 Jan 2002, Mike McCormack wrote: looks good to me. The only complication i can see is if overlapped operations are possible on consoles. Yes, but the OVERLAPPED flag must be set explicitly by the get_file_info() method of the corresponding server object. console_get_file_info() will simply leave this flag unset if overlapped operations are impossible on consoles. The idea is that get_file_info() has a more flexible way to communicate the capabilities of a file descriptor; this doesn't imply all fields are completely independent of each other. Martin -- mailto:[EMAIL PROTECTED] ph +82 16 430 0425 __ Get your free Australian email account at http://www.Looksmart.com.au
Re: [RFC] cleaner FD_TYPE_XXX implementation
Yeah, if there is such a thing a s an overlapped console in the future, the ReadFile() code must make a more fine-grained distinction. Unlike before, though, ReadFile() will now know that it is an overlapped console rather than simply an overlapped fd. Similar arguments may hold for other IO objects, too. Thanks for commenting, Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
ReadFile() question (Bug?)
Btw, in the code in ReadFile() / WriteFile() handling consoles, shouldn't there be a close (unix_handle) statement before calling ReadConsoleA() / WriteConsoleA() ? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Wine Tasklist
On Thu, 3 Jan 2002, Francois Gouget wrote: * Move the winsock16 code to wsock32 Is anybody working on this right now? I am not working on it currently and I am not aware of anyone else working on it. Go ahead! What you propose means that winsock16 will be owned by winsock32, which will, in turn, forward most calls to ws2_32 (as it does now), right ? I don't know if I'll be able to sort this out, because my understanding of the Wine linking issues and the spec files is yet very limited. To make matters worse, the Winsock code has some problems with symbol clashes between system headers and wine headers. I'll see what I can do. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Debugger on Solaris
On Fri, 4 Jan 2002 10:49, Alexandre Julliard wrote: Robert Lunnon [EMAIL PROTECTED] writes: Without calling ptrace (TRACEME,...) Solaris returns ESRCH even though the process exists which causes the wineserver to assume the process is defunct and delete the app, apparently causing the deadlock (This deadlock will have to be fixed too !). Are you sure this is not rather an issue of process id vs. thread id? I would be surprised if Solaris required TRACEME in this case, since this would mean you couldn't attach a debugger to a running process.
Lindows screenshots
Hi, I just got this - Lindows released 2 screenshots of their Lindows: www.lindows.com/screenshots Now, IF they did use wine (and thats a big if - from the screenshots they're running either Office 2K or office XP, Internet Explorer, the fonts looks like MS TTF fonts, and I think those screenshots are modified a bit - look at the 2nd screenshots, behind the start menu - look at the file/edit/view menu - it should be alligned to the left) and they'll contribute some parts of their wine to the standard wine - then wine will be in much better shape then what is it today. Hetz
Re: Lindows screenshots
Thisn is going to be a fun one - think of all the M$ patents and EULA's they are breaking :) M$ might leave us alone - but a competative product looking that much like windows? No chanec. Which probably means we'll never see a line of code.. A) Because they'll keep it to themselves, and B) because they'll be out of buisness within a month of first sales. Call me a cynic :p Regards,| Any significantly advanced technology is | indistinguishable from a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Fri, 4 Jan 2002, Hetz Ben Hamo wrote: Date: Fri, 4 Jan 2002 12:48:14 +0200 From: Hetz Ben Hamo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Lindows screenshots Hi, I just got this - Lindows released 2 screenshots of their Lindows: www.lindows.com/screenshots Now, IF they did use wine (and thats a big if - from the screenshots they're running either Office 2K or office XP, Internet Explorer, the fonts looks like MS TTF fonts, and I think those screenshots are modified a bit - look at the 2nd screenshots, behind the start menu - look at the file/edit/view menu - it should be alligned to the left) and they'll contribute some parts of their wine to the standard wine - then wine will be in much better shape then what is it today. Hetz
Re: msnbc news alert installer: Unable to start browser
Dan Kegel [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... While doing research for my site on the Microsoft antitrust trial ( http://www.kegel.com/remedy/ ), I came across a nasty little EULA for a product called MSNBC News Alert. The EULA is at http://www.msnbc.com/tools/newsalert/naeula.asp and says MSNBC Interactive grants you the right to install and use copies of the SOFTWARE PRODUCT on your computers running validly licensed copies of the operating system for which the SOFTWARE PRODUCT was designed So who specifies for what operating systems the software was designed? [e.g., Microsoft Windows(r) 95; Microsoft Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.]. It'd be nice to know how close Wine is to being able to (a) install and (b) run this on a fake windows installation, as this may have some bearing on whether Microsoft is damaging anybody with this exclusionary EULA. (Besides, how could I resist? That EULA practically begs to be disobeyed!) It seems to me that one cannot even tell whether one is or is not disobeying it. Bill
Re: Lindows screenshots
J.Brown (Ender/Amigo) [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Thisn is going to be a fun one - think of all the M$ patents and EULA's they are breaking :) M$ might leave us alone - but a competative product looking that much like windows? No chanec. Did you notice that M$ are already on the offensive; they are going to court over the name itself. Bill
Re: Lindows screenshots
Hetz Ben Hamo [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, I just got this - Lindows released 2 screenshots of their Lindows: www.lindows.com/screenshots Now, IF they did use wine (and thats a big if Why? It looks to me like KDE Wine and enough hard work to get a couple of office apps up with some reasonable fonts (and the usual minimal touchup work for marketing screenshots) Cut menu - it should be alligned to the left) and they'll contribute some parts of their wine to the standard wine - then wine will be in much better shape then what is it today. I wouldn't hold my breath; why would they contribute the valuable stuff back? Bill
Re: Wine Tasklist
On Fri, 4 Jan 2002, Martin Wilck wrote: On Thu, 3 Jan 2002, Francois Gouget wrote: * Move the winsock16 code to wsock32 Is anybody working on this right now? I am not working on it currently and I am not aware of anyone else working on it. Go ahead! What you propose means that winsock16 will be owned by winsock32, which will, in turn, forward most calls to ws2_32 (as it does now), right ? Yes. I don't know if I'll be able to sort this out, because my understanding of the Wine linking issues and the spec files is yet very limited. To make matters worse, the Winsock code has some problems with symbol clashes between system headers and wine headers. I mostly meant that you could go ahead with the changes that you had planned to do in Winsock. But of course you are welcome to tackle this too. If you do, I will try to help as I can. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
Re: Lindows screenshots
Yeah, M$ is claiming that they got -indows as a registered trademark. But, they tried to register Windows (by itself) as a registered trademark a few years back. But they got turned down because the word windows is a common English word. They cannot register word suffices as registered trademarks IMO. Personally, who is going to confuse between Windows and Lindows? If one isn't paying attention, they may sound similar, but in print, they are unmistakingly different. It's yet another abuse of their monopoly status. Just my two cents worth. ** Derek J Witt ** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** ...and on the eighth day, God met Bill Gates. - Unknown ** On Fri, 4 Jan 2002, Bill Medland wrote: Date: Fri, 4 Jan 2002 07:48:37 -0800 From: Bill Medland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Lindows screenshots J.Brown (Ender/Amigo) [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Thisn is going to be a fun one - think of all the M$ patents and EULA's they are breaking :) M$ might leave us alone - but a competative product looking that much like windows? No chanec. Did you notice that M$ are already on the offensive; they are going to court over the name itself. Bill
SHGetSpecialFolderLocation function
Hi, I've been looking into this function, trying to work out why ms office 97 can't install under Wine. (I've also been looking at the handling of command-lines when new processes are spawned, as office's setup program spawns a process called acmsetup with a string of command-line options, and it seems that wine manages to insert an extra at the end of the command line.) What I've found though with the SHGetSpecialFolderLocation, is that it seems to me that it is designed to allow the caller to pick an arbitrary value for the CSIDL, and that this will cause windows to create a new CSIDL. As the function's implementation currently stands, it has a hard-coded table of possible CSIDLs, and rejects calls with unknown CSIDLs. Has anyone else looked at this function, and does anyone have any comments or suggestions on ways to address this? I'm thinking that these values probably need to go into the registry, or something, rather than being stored in the code... regards Chris Green
Re: MSDOS Error Table Handling
In [EMAIL PROTECTED], on 01/04/02 at 09:46 AM, Ove Kaaven [EMAIL PROTECTED] said: : - INT (WINE-only interrupt) :If that's what you need, I suggest allocating a DPMI Real-Mode Callback :thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use :it in dosaspi.c... you give it a Wine-implemented function, and it :returns a real-mode address that DOS apps can use to call it... the only :thing to keep in mind is that it's the Wine function's responsibility to :pop the real-mode stack) Thank you for pointing out the DPMI function to me. However, before discussing the advantages and disadvantages of your suggestion, I feel obligated to point out that all I have done is to fix the existing broken code, and therefore can not speak to what design alternatives the original author may have considered. In fact, my search of the change logs has failed to find any mention of DOSMEM_InitErrorTable whatsoever. If the original author of this code still follows the wine-devl list, perhaps he or she will enlighten us. Speaking for myself, the phrase WINE-only interrupt is misleading. The reality is that DOS uses int2f ax:0x122e for setting and getting the address of various error tables. The specific routine is selected by the value in dl, of which only the values 0-9 are defined. My fix adds dl:0x7f as the wine routine which moves the requested error message to the real mode buffer. To me, it seems that the only advantage to using the DPMI callback mechanism in this specific case, is that it would save nine bytes of real mode memory, at a cost of degraded performance and increased code complexity. However, if you feel strongly about it, I will defer to your judgement. -- Chuck Crayne --- [EMAIL PROTECTED] ---
Re: ReadFile() question (Bug?)
Hi Martin, The console doesn't use an fd, so no fd will be fetched in FILE_GetUnixHandle. (have a look at server/console.c) Mike Btw, in the code in ReadFile() / WriteFile() handling consoles, shouldn't there be a close (unix_handle) statement before calling ReadConsoleA() / WriteConsoleA() ? Martin -- mailto:[EMAIL PROTECTED] ph +82 16 430 0425 __ Get your free Australian email account at http://www.Looksmart.com.au
