January 2003 - Wine-Devel - list.winehq.org

Re: RPC marshalling patch

by Ove Kaaven

On Thu, 30 Jan 2003, Greg Turner wrote: > On Thursday 30 January 2003 10:44 am, Ove Kaaven wrote: > > This one is sure to give Greg something to work with... > > looks very interesting, indeed. > > > all of this was > > implemented in a bit of a hurry, but since it's based on my research, it > > should be a good starting point in understanding how Microsoft's NDR > > engine works. It doesn't properly implement marshalling alignment or > > memory sizing, may not handle a number of fringe cases, does not conform > > to the DCE RPC wire protocol (mostly because I don't have a description of > > it... where did you find it, Greg?), and probably needs some cleanup, but > > I think, I had to sign away my firstborn to OpenGroup for it. If you feel > like spending money /and/ signing away your firstborn, this looks like the > definitive OpenGroup DCE package: > > http://www.opengroup.org/products/publications/catalog/t151x.htm I can't find any legalese there to the effect of signing away my firstborn, they seem to just want purchase details. Care to elaborate? (And is it still okay for me to code on Wine even if my firstborn can't?) > and here is some free-as-in-beer RPC 1.1 stuff: > > http://www.opengroup.org/products/publications/catalog/c706.htm And on there, they just want to borg the email addresses of every reader, but not their souls or firstborns, as far as I can see. > In your previous patch you mentioned the possibility of a merge situation > between us. Indeed, this is probably the case, but it's minor. I've been > real busy lately with work, and other non-wine things, so I haven't been > forging ahead at my usual clip. There's not a whole lot floating around in > my tree that hasn't gone out to wine-patches ATM. OK.

Jan. 31, 2003

Re: RPC marshalling patch

by Greg Turner

On Thursday 30 January 2003 10:44 am, Ove Kaaven wrote: > This one is sure to give Greg something to work with... looks very interesting, indeed. > all of this was > implemented in a bit of a hurry, but since it's based on my research, it > should be a good starting point in understanding how Microsoft's NDR > engine works. It doesn't properly implement marshalling alignment or > memory sizing, may not handle a number of fringe cases, does not conform > to the DCE RPC wire protocol (mostly because I don't have a description of > it... where did you find it, Greg?), and probably needs some cleanup, but I think, I had to sign away my firstborn to OpenGroup for it. If you feel like spending money /and/ signing away your firstborn, this looks like the definitive OpenGroup DCE package: http://www.opengroup.org/products/publications/catalog/t151x.htm and here is some free-as-in-beer RPC 1.1 stuff: http://www.opengroup.org/products/publications/catalog/c706.htm Where, exactly, I got what I have is a bit of a mystery to me :( It looks like it started its journey as postscript so perhaps it's part of the DCERPC source tarball? My old box is booted into the Operation Flashpoint Operating System... er... Windows, I mean... so I can't dig it out from my ext3 partition right now. In your previous patch you mentioned the possibility of a merge situation between us. Indeed, this is probably the case, but it's minor. I've been real busy lately with work, and other non-wine things, so I haven't been forging ahead at my usual clip. There's not a whole lot floating around in my tree that hasn't gone out to wine-patches ATM. -gmt

Jan. 31, 2003

Re: Why is IOCTL_CDROM_READ_TOC so slow?

by Waldeck Schutzer

Here is something interesting. When I turn the drive back into a plain ide (by removing the ide-scsi option from the kernel options), it speeds up considerably. Now it rocks! This makes me wonder what the heck is going on with the kernel. Waldeck Eric Pouech wrote: > Waldeck Schutzer wrote: > >> Hi Eric, >> >> It is very strange indeed, but I just tested it again and I'm >> convinced that on my system that call can take a few seconds. I'm >> also pretty sure there is no concurrent access to the drive and >> automount is not running. I even did this on a failsafe session just >> to be sure, but still the same thing. > > maybe you could try it with a simple C program: > 1/ open fd > 2/ do the read toc ioctl > 3/ close > time the operation 2/ > > > I wonder there is something wrong with my kernel (2.4.18), > >> or worse, with my computer. On the other hand, it works pretty fast >> on Windows. > > rather strange... I reran on my computer win98 cdplayer, and > everything's ok. > I wonder if the CD ROM driver in Linux is not to blame then > > A+

Jan. 31, 2003

Re: wrc: merge README.wrc into the man page

by Dimitrie O. Paun

On January 30, 2003 09:38 pm, Dimitrie O. Paun wrote: > ChangeLog > Merge README.wrc into wrc's man page. Sorry I forgot to mention, also do: cvs rm -f tools/wrc/README.wrc before you commit. -- Dimi.

Jan. 31, 2003

Re: [RFC] The Wine UI page

by Dimitrie O. Paun

On January 30, 2003 03:59 pm, Eric Pouech wrote: > this matrix about status(es): on one side the various DLLs we're working > on, on the other side some metrics/characteristics we want to > highlight... and working only by rows or columns is not very efficient > I also agree that working on the ful matrix would be also difficult (at > least to put it in place) Whether such a matrix is usable (may be too big) is not clear to me. But it's an interesting idea. However, the hard part is the content, and that's difficult to get. Once I finish this page, maybe we can create a unifing matrix, see how it looks. > another piece, I forgot about some other control(s) (and here it's more > than a simple control): > - MCIWndClass in msvideo/msvfw32 Can you please help me complete the entry: -- URL to MS docs -- status (% completion, what it's missing) -- maybe to an audit against the latest MS docs, see _exactly_ what we're missing. I've put something there, but I'm afraid it's not right. Check it out. -- Dimi.

Jan. 31, 2003

half-life

by Scott Jackson

halflife majorly crashes on me: err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 112 bytes for thousands of lines, until it eventually pukes and wants to debug. then it tells me: Couldn't start process '148738992 0x84 ' (twice) Why? I don't know. I remember installing it under wine, but it always puked on me like that afterwards. I have 128MB of RAM so that shouldn't be a problem. -- "De-fault! The two sweetest words in the English language." -- Homer Simpson Get Gaim for unix or win32 systems! gaim.sourceforge.net Scott "Action" Jackson - scott_j(a)ajackson.org

Jan. 30, 2003

font metrics

by Scott Jackson

how can I force wine to do font metrics? -- "De-fault! The two sweetest words in the English language." -- Homer Simpson Get Gaim for unix or win32 systems! gaim.sourceforge.net Scott "Action" Jackson - scott_j(a)ajackson.org

Jan. 30, 2003

Re: japanese fonts

by Scott Jackson

Well, I'm off to try that. I tried a mv /usr/X11R6/whereverthefontswere/ to a back up dir, then reset xf86 and wine worked fine... I'd like to believe that it was the fonts' fault, but everywhere else they work fine. I dunno my japanese fonts go funky on me sometimes... methinks kappa is a bitmap font? if there's development to be done, then I might be able to send y'all (texas native) a tar.bz2 file of what is messing up. One of the other restrictions I have as far as japanese fonts, is that whenever mozilla is asked to render a bold SHIFT_JIS type font, it gives me blank space. All information is available, just ask ;-) Your friendly neighborhood (texan) wine user, Scott On Wed, 29 Jan 2003 23:06:51 -0800 (PST) liu spider <liuspider(a)yahoo.com> wrote: > I think it's not the wine's fault. > > Just try to copy or link a Japanese font to the dir: > c/windows/fonts/ > > This works for me. >

Jan. 30, 2003

Re: [RFC] The Wine UI page

by Eric Pouech

>>IMO, this type of information should be integrated in current status page. > > Sure, it's just so much easier to work with it on my site. > I am a bit concerned that merging this page with the big > status page will result in a huge page that is not that > useful. I think that UI elements deserve a special place > (I have not explained yet why I think so, that's another > matter). Nevertheless, once this thing stabilizes, it can > be integrated in the big status page if people feel it's > a good idea. Or we can put it on the official site as a > separate page, and link to it from the main status page. > Details, let's get the content down first. :) what worries me is that status, from a DLL point of view, could be seen from different angles: - current status page gives an overall status, without focusing on any particular detail - you start creating another status page about the UI status of Wine - some good other fellow might want to start with, say, Unicode status in various DLLs or level of comments or attached bugs or... this matrix about status(es): on one side the various DLLs we're working on, on the other side some metrics/characteristics we want to highlight... and working only by rows or columns is not very efficient I also agree that working on the ful matrix would be also difficult (at least to put it in place) another piece, I forgot about some other control(s) (and here it's more than a simple control): - MCIWndClass in msvideo/msvfw32 A+ -- Eric Pouech

Jan. 30, 2003

Re: RPC marshalling patch

by Joerg Mayer

On Thu, Jan 30, 2003 at 05:44:35PM +0100, Ove Kaaven wrote: > does not conform > to the DCE RPC wire protocol (mostly because I don't have a description of > it... You could take a look at the Ethereal sniffer software (www.ethereal.com) It has dissectors for some of Microsofts rpc stuff. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Jan. 30, 2003