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

Re: Wine Status Page Pre-1
by Brian Vincent (C) Dec. 17, 2003

Dec. 17, 2003

> 3) Send to Brian V for WWN coverage :) (Brian if you want you can get a > early start) Hm. 1.7 meters of snow this week at Steamboat and I have the next three days off. I'm guessing I won't have much done until Monday. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Input Focus problems with IE
by Aric Stewart Dec. 17, 2003

Dec. 17, 2003

Hello, I am working on a problem with IE where if you start the application in full screen mode: (start IE, change to full screen using view->full screen, shutdown IE, restart IE) the keyboard focus never gets given to the application so you cannot enter any information into forms. Looking into this i found that we where never being given any ClientMessage events to take focus nor any FocusIn events. So the keyboard focus remains on whatever app last had it, such as the terminal used to start IE. A very simple, shotgun, way to solve this is this attached patch. Thinking about windows architecture i was trying to think of a time where a window would receive a button click and would not be given input focus (yes the app may modify focus but it would do that anyway) However this change is HUGE and will affect alot and wanted to bounce it off people before continuing to investigate it. This look ok to people? Other ideas on proper ways to deal with this issue? thanks -aric Index: dlls/x11drv/event.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/event.c,v retrieving revision 1.30 diff -u -w -r1.30 event.c --- dlls/x11drv/event.c 5 Dec 2003 04:45:50 -0000 1.30 +++ dlls/x11drv/event.c 16 Dec 2003 19:02:57 -0000 @@ -287,6 +287,14 @@ break; case ButtonPress: + /* + * I am sort of unsure about this however + * there should not be a case where the button is clicked somewhere + * and windows does not assume focus is sent there. + * + * it also fixes a bunch of input problems for forms in IE + */ + set_focus(hWnd,CurrentTime); X11DRV_ButtonPress( hWnd, (XButtonEvent*)event ); break;

3 4

Re: default config file creation
by Ivan Leo Murray-Smith Dec. 17, 2003

Dec. 17, 2003

> If wine-c is stored uncompressed, it's easier for a site admin to modify > it for all its users. True, but this shouldn't be necessary. Also any global configuration should be done via winecfg. > Also, there are a couple places in Wine which are dependant on how the > underlying distribution is setup, things like menu entries and such. Not > every distro ship a vanilla Gnome or KDE (and then there are many > versions of each). Sure, after all I ship mime types files and menu entries for the mandrake menu system in mdk rpms, but I'm reluctant to change the actual application source code, because the same source should work for all (After all that's why we use autoconf), so if any changes are needed, they should go in the CVS, and consequentially end up in all packages Ivan.

1 0

Re: default config file creation
by Ivan Leo Murray-Smith Dec. 17, 2003

Dec. 17, 2003

>I was chatting with Rudolf Kastl(che on #winehq) and he was mentioning the >things that he was doing for the rpm package. One of the patches he applies >to wine prior to packaging it is a patch that creates local user config files >if they don't exist. His patches modify wine/libs/wine/config.c and wine/misc/registry.c, I don't see the need to change things, they could do if Alexandre accepts them in the CVS. They would uniform wine packaging, and make things easier, also wine-c could be a comprssed dir as it's only usility would be to be copied to $HOME, it doesn't really need to be uncompressed in /usr/share. Of course, all packagers could just apply these patches to binaries, but official packages should just ship vanilla wine (Otherwise why call them "official"?), so this depends on Alexandre. Ivan.

2 1

Re: Fix for Japanese Font Names
by Michael Stefaniuc Dec. 17, 2003

Dec. 17, 2003

Hi, could you please resubmit your diff using the unified output format? See http://www.winehq.org/site/sending_patches for details. bye michael On Wed, Dec 17, 2003 at 12:00:56PM +0900, Vik wrote: > May last patch had some wrong font names for Japanese resource files. > The correct name for MS UI Gothic is 'Gothic' in English, and not 'Gothic' in > Japanese. > > Changelog > + fixed MS UI Gothic Font names in: > dlls/commdlg/cdlg_Ja.rc > dlls/user/resources/user32_Ja.rc -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Always add a \ to temp file path
by Steven Edwards Dec. 16, 2003

Dec. 16, 2003

There is a prepackaged binary that works great for me on slackware if you want it. Builing one from scratch is to much of a pain in the ass. http://www.libsdl.org/extras/win32/cross/README.txt Thanks Steven --- Mike Hearn <mike(a)theoretic.com> wrote: > The NullSoft installer assumes this will be present, so it most > likely > always is on Windows. When I get a cross compiler setup (soon, > promise!) > I'll try writing a test case for this behaviour. > > Mike Hearn <mike(a)theoretic.com> > Always add a \ to temp file path. Add a warning to DeleteFile. > > Index: files/file.c > =================================================================== > RCS file: /home/wine/wine/files/file.c,v > retrieving revision 1.196 > diff -u -r1.196 file.c > --- files/file.c 12 Dec 2003 04:10:52 -0000 1.196 > +++ files/file.c 16 Dec 2003 19:47:04 -0000 > @@ -921,10 +921,8 @@ > strcpyW( buffer, path ); > p = buffer + strlenW(buffer); > > - /* add a \, if there isn't one and path is more than just the > drive letter ... */ > - if ( !((strlenW(buffer) == 2) && (buffer[1] == ':')) > - && ((p == buffer) || (p[-1] != '\\'))) *p++ = '\\'; > - > + *p++ = '\\'; > + > for (i = 3; (i > 0) && (*prefix); i--) *p++ = *prefix++; > > unique &= 0xffff; > @@ -1556,7 +1554,11 @@ > return FALSE; > } > > - if (!DOSFS_GetFullName( path, TRUE, &full_name )) return FALSE; > + if (!DOSFS_GetFullName( path, TRUE, &full_name )) > + { > + WARN("Unable to get full name from %s\n", debugstr_w(path)); > + return FALSE; > + } > > /* check if we are allowed to delete the source */ > hFile = FILE_CreateFile( full_name.long_name, > GENERIC_READ|GENERIC_WRITE, 0, > > > __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

1 0

Re: Fix kernel heap test
by Dimitrie O. Paun Dec. 16, 2003

Dec. 16, 2003

On December 15, 2003 10:35 am, Hans Leidekker wrote: > The test succeeds on Wine. This is wrong of course, tests should > always succeed on Windows and either succeed on Wine or fail on > Wine and be marked todo_wine. Great, thanks for catching this. Our current implementation seems to be freeing memory on size=0, how can we check what Windows does? If it doesn't, we can just simpligy the code to this: Index: dlls/kernel/heap.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/heap.c,v retrieving revision 1.4 diff -u -r1.4 heap.c --- dlls/kernel/heap.c 27 Nov 2003 00:59:36 -0000 1.4 +++ dlls/kernel/heap.c 15 Dec 2003 16:19:04 -0000 @@ -615,37 +614,15 @@ SetLastError(ERROR_INVALID_HANDLE); } else #endif - if(size!=0) - { - hnew=hmem; - if(pintern->Pointer) - { - if((palloc = HeapReAlloc(GetProcessHeap(), heap_flags, - (char *) pintern->Pointer-HGLOBAL_STORAGE, - size+HGLOBAL_STORAGE)) == NULL) - hnew = 0; /* Block still valid */ - else - pintern->Pointer = (char *)palloc+HGLOBAL_STORAGE; - } - else - { - if((palloc=HeapAlloc(GetProcessHeap(), heap_flags, size+HGLOBAL_STORAGE)) - == NULL) - hnew = 0; - else - { - *(HGLOBAL *)palloc = hmem; - pintern->Pointer = (char *)palloc + HGLOBAL_STORAGE; - } - } - } + if(size == 0) size = 16; + hnew=hmem; + if(pintern->Pointer) palloc = HeapAlloc(GetProcessHeap(), heap_flags, size+HGLOBAL_STORAGE); + else palloc = HeapReAlloc(GetProcessHeap(), heap_flags, (char *) pintern->Pointer-HGLOBAL_STORAGE, size+HGLOBAL_STORAGE); + if (!palloc) hnew = 0; else { - if(pintern->Pointer) - { - HeapFree(GetProcessHeap(), 0, (char *) pintern->Pointer-HGLOBAL_STORAGE); - pintern->Pointer=NULL; - } + pintern->Pointer = (char *)palloc + HGLOBAL_STORAGE; + if (!pintern->Pointer) *(HGLOBAL *)palloc = hmem; } } } -- Dimi.

2 1

Re: Implement support for many MCIWndClass MCI_ and MCIWNDM_ messages
by Dimitrie O. Paun Dec. 16, 2003

Dec. 16, 2003

On December 15, 2003 03:12 am, Dmitry Timoshkov wrote: > What remains to be done is a proper support for MCI_WINDOW > command in mciavi.drv. Cool stuff Dmitry! Now that this stuff is in the tree, would it be fair to mark this on the status page as 75% complete? What's still left to do? Eric was saying that we needed (before your patch): - missing extended styles, notification, MCIWNDM_* I guess you did the MCIWNDM_* stuff, but the notification is still a TODO. Is the TODO list still too big to be listed in its entirety? -- Dimi.

2 1

Re: Internally maintained end-to-end API documentation
by Brian Vincent (C) Dec. 16, 2003

Dec. 16, 2003

> After reading Wine Weekly News Issue #200, (Congrats > by the way), I stumbled across the Wine Status Pages. Thanks. > In my humble opinion, this is a very dangerous and > volatile place to have it. It is volatile and there have definitely been instances of people wondering where documentation has disappeared to. > This is quite tragic as my knowledge of XML is really > weak. As far as I know, it's that HTML superset, isn't > it? SGML is the one document format To Rule Them All. XML is a subset of that. HTML is a subset of XML (and therefore SGML). Realistically, Wine could probably use XML for all its documents. But we use SGML since that was around first. We convert the SGML into various nice document formats depending on how it's used. If you know HTML then you won't have much of a problem marking up SGML. > Stepping back a bit, I started thinking of tossing an > SQL database on one of my machines and writing some > kind of dynamic HTML front end for it. I wouldn't. Wine has lots of tools in use for building and searching documentation, not the least of which is "grep". > The second hurtle is what to put as the actual > fields. I'm really only used to seeing function > rendered an a "Unix man style" format. Name, synopsis, > description, return value, errors, bugs. I actually really like this idea. The standard C library is nicely documented in man pages, why shouldn't Win32 be the same way? I don't think we need another document format or repository (Side note, is it just me, or is the GNU texinfo format the stupidest form of documentation ever invented..) The important thing is, keep the documentation in a format that is easily modifiable by developers. Since most have a copy of CVS laying around that probably means keeping docs in a text format somewhere in the documentation/ directory. The scope of this project is huge. In some ways you're trying to recreate MSDN, and as Greg pointed out that documentation lives on real media in the hands of thousands of people. Yes, it might be nice to replicate that but copyright issues are something you'll need to be aware of. If you rewrite all of it by hand you definitely won't infringe on copyrights, but is there an easier way put it together? Something tells me there's already some resources out there that could be used as a foundation. Also, be sure to read the "Terms of Use" link at the bottom of msdn.microsoft.com. It may as well just say "You can only read our web pages." A quick search on Google alludes to people writing man pages for Win32. This was on a NetBSD mailing list: http://mail-index.netbsd.org/netbsd-bugs/2001/05/17/0008.html >Number: 12974 >Category: pkg >Synopsis: w32doc-borland - man pages for the win32 api >Confidential: no >Severity: non-critical >Priority: low >Responsible: pkg-manager >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Thu May 17 13:16:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Ben Collver >Release: 1.5 >Organization: >Environment: >Description: >A set of Unix-like man pages for the Windows 32 API. This package creates >a new manual section (wb) containing man pages derived from a Windows >help file distributed by Borland for Delphi2. Once installed, you could for >example read the WinMain man page by typing "man wb WinMain". >This documentation is not as up-to-date as that in devel/w32doc. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

2 1

Re: TDI + NetBIOS = Network Neighborhood
by Luke Kenneth Casson Leighton Dec. 16, 2003

Dec. 16, 2003

hi, wrote to the wine-devel mailing list about this one describing a few words about what's needed to be done to "support" your efforts. documentation. rfc1001.txt and rfc1002.txt - these describe NBT (netbios over tcp) and how to get: - datagrams (port 138) equivalent to UDP - sessions (port 139) equivalent to TCP - names (port 137) LISTEN UP! THIS IS EQUIVALENT TO DYNAMIC-DNS + DHCP! the last one of these needs careful explanation. in light of the recent attempts by the wireless IETF crowd to create a dynamic routing protocol is is _totally_ ironic that netbios got there first _by over twenty years_ - and that there is a FREE implementation for the taking, in nmbd. it's also pretty ironic because they've had to play catch-up with concepts like node status queries in additional extension draft rfcs, and they STILL haven't added the "name conflict" concept which is there to tell anyone that will listen that a name which is attempting to be claimed is being taken by someone else who won't give it back. port 137 _is_ actually dns, so if you happen to know of any wine-licensing compatible DNS client code then you can use that as the basis for your efforts. it's dns but it's extended: the names of the types of packets mean slightly different things; there is additional packet types to represent NAME_REGISTER and NAME_STATUS; there is also a different CNAME type to cope with netbios names; the "dns zone" is there it's called a "scope"; the "dns name" is "compressed" it's a brain-dead misnomer given that the name is actually expanded in some sort of stupid base-4 (no, not base-64, yes, that's right, base-4) encoding scheme that turns a 16-byte space-padded thing into an overbloated 64-byte monster. cifsbrow.txt. eek, it's been a while. have a look at www.cb1.com/~lkcl/ntdom. no, try this: http://www.monyo.com/technical/samba/rfc/ actually, first try this: http://ubiqx.org/cifs/References.html which will give you a better idea of what the other one contains: the ftp://ftp.microsoft.com/developr/drg/CIFS directory appears to be inaccessible, now, which is just typical. basically you should read cifsbrow.txt in conjunction with rfc1001.txt and rfc1002.txt. SKIM THEM! YOU ONLY NEED A MINIMAL SUBSET OF THOSE DOCUMENTS FOR A CLIENT IMPLEMENTATION!!!! the only reason that you need to read those docs - skimmed - is because you need to know what you are going to be communicating with (not implementing, server-side, just connecting to, client-side). all you _really_ need is to be able to do a NetBIOS name query and also to be able to do a couple of SMB queries to obtain lists of servers. THAT IS ALL THAT A CLIENT-SIDE NETWORK NEIGHBOURHOOD BROWSER IS. REALLY! if you're implementing this from scratch, however, expect to allocate about ... mmm ... anywhere between four and eight weeks. i _thoroughly_ recommend that you investigate finding some dns client code to adapt and save yourself some time with decoding port 137. also, while you're at it, you might want to next focus on the contents of the ntnp.doc file which was last available with the ms-dev that contained visual studio 4.3. ntnp.doc stands for nt network provider and it had a companion "client-side" document to describe the other bit that went with it. basically there is a "redirector" protocol on both client _and_ server-side that covers browsing. these two protocols "merge" the network neighbourhoods into one big happy family, such that netware's network neighbourhood can be installed and cooperate happily with the smb network neighbourhood can be installed and cooperate happily with the kerberos-domain-based network neighbourhood and it was all one big happy family yippee. so, whilst you may believe that it is best to implement the network neighbourhood browsing functions as "direct" as possible, if you ever install the "client for netware" under wine and then wonder why it doesn't appear in the network neighbourhood, remember what i said in the paragraph above!! l.

1 0