- Wine-Devel - list.winehq.org

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

Vacation
by Alexandre Julliard Dec. 15, 2003

Dec. 15, 2003

Folks, There won't be any commits for a while, since I'm leaving now for a vacation in Switzerland, where I won't have net access. Assuming I survive the deprivation, I'll be back in two weeks. I hope you all have nice holidays, and I look forward to finding a few hundred patches in my mailbox when I get back... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Fix ntdll test
by Alexandre Julliard Dec. 15, 2003

Dec. 15, 2003

Hans Leidekker <hans(a)it.vu.nl> writes: > Uncomment some tests in rtlstr.c and wrap them in todo_wine{} instead. You can't do that, many of these tests succeed, which is not allowed inside todo_wine. And please try a 'make test' when you change a test, as already explained there's no point in submitting a patch that causes make test to fail. -- Alexandre Julliard julliard(a)winehq.com

2 1

netapi32 and NetBIOS
by Luke Kenneth Casson Leighton Dec. 15, 2003

Dec. 15, 2003

[sent also to samba-technical mailing list] hi, i've just been alerted to the netbios work in wine (hooray!) as part of an effort to get the network neighbourhood going (yippee!). there is a problem, which i can help overcome. the problem is this: imagine that there is no TCP/IP stack in linux. imagine that TCP/IP runs in two separate user-space services, both of which are GPL'd: the TCP service is a fork-on-demand one that binds to all interfaces, and the UDP service is even worse, it's a single-process running a state machine. let's pretend that neither of the processes understand anything but Web services, and now you want to add SMTP, or worse, HTTPS. you have to consider hard-coding and linking into a paired monolith of programs, and you have a licensing and logistical nightmare that is totally unacceptable for practical purposes. this is the situation that is faced by wine, because samba, which consists of two programs, smbd and nmbd, "controls" the NetBIOS transport, from both a server _and_ (due to some bugs in Windows) also a client perspective. a flawed attempt to make it possible to cut-in to the NetBIOS equivalent of Dynamic-DNS-plus-DHCP (the NBNS system on port 137) was added in 2000 into nmbd, however from the Wine perspective this is totally useless because the code to access the bypass mechanism is GPL'd (tdb - trivial database). happily there is a convenient way round the mess, because it is possible to create the equivalent of a "Network Address Translation" service, and working code along these lines, which maintained a state machine of NetBIOS connections, was created over three years ago. nmbd needs to talk via this NAT service, so does nmblookup and, once the code is all there, so does Wine's Network Neighbourhood browsing code. at present, all you have to do to get the Wine "Network Neighbourhood" code to work is to disable samba, which is going to be totally impractical for most people. it is not _yet_ necessary for such a service to be created, but by the time the NetBIOS code in wine is released, it will _become_ necessary. if anyone wants to sponsor me [pay money] to revive the experiments i made in late 1999 / early 2000 in order to implement a NetBIOS "NAT" service, please contact me. l. -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about...

1 0

uxtheme clips to much
by hatky Dec. 15, 2003

Dec. 15, 2003

I know these are stubs but since they were added more of the splash screen and the top of the main application of Trillian has been cut off freeware at: http://download.com.com/3000-2150-10047473.html?part=trillian&subj=dlpagtag… home page at: http://www.ceruleanstudios.com/downloads/ Hatky. __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

2 2

Extended window flag
by Fabian Cenedese Dec. 15, 2003

Dec. 15, 2003

Hi I have an application where I get the styles from a window with GetWindowLong(m_hWnd, GWL_EXSTYLE); In Windows I get 0x00000110 but in wine I get 0x40000110. From the wine headers (mine seem to old) I get this means 'managed by the system'. Is this something wine specific? Do I need to pay attention to this? If it's a valid Windows flag why isn't it set in Windows? If it's just wine specific can I just mask it out? Thanks bye Fabi

3 6

Re: Running Wine under MS SFU under Wine ... ?
by ea＠iol.it Dec. 15, 2003

Dec. 15, 2003

> My real point is - SFU is yet another set of windows > programs we can use to test wine, may as well grab a > copy while they're 'free'. SFU3 contains also the POSIX personality for NT/2k. Does Wine run native NT apps yet?

1 0

Wine Segmentation fault
by Fabian Cenedese Dec. 15, 2003

Dec. 15, 2003

Hi I have a problem with starting wine itself. After trying the CodeWeavers wine I wanted to get clean again and removed everything I could find only slightly wine related (/usr/bin, /usr/local... etc). I even removed my cvs of wine of a few days ago. Then I made a fresh checkout and did the complete install with wineinstall. But still after this whole procedure I cannot start wine. Any ideas? Knoppix (Kernel 2.4.22) fabi(a)lx_fabi:/usr/local/bin$ gdb wine GNU gdb 5.3-debian Copyright 2002 Free Software Foundation, Inc. .. snip .. This GDB was configured as "i386-linux"... (gdb) run Starting program: /usr/local/bin/wine Program received signal SIG32, Real-time event 32. 0x40046fc4 in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) bt #0 0x40046fc4 in pthread_getconcurrency () from /lib/libpthread.so.0 #1 0x40046e08 in pthread_getconcurrency () from /lib/libpthread.so.0 #2 0x400463f2 in pthread_create () from /lib/libpthread.so.0 #3 0x00110de6 in get_threading () at glibc.c:61 #4 0x00110e2e in main (argc=1, argv=0xbffffc74) at glibc.c:73 Thanks bye Fabi

3 4