Wine Traffic #209 For 6 Jan 2004

1. no dynamicity in DOS drive management: user should be able, in his/her session(1), to either change the mapping of a DOS drive letter, or mount a SMB share somewhere...)
2. mounting should be done session wide and not process wide, and of course shared across processes
3. ntdll and kernel32 are not separated regarding file management
4. devices (vxd and DOS) management is still a hack
5. it may be necessary to introduce a notion of filesystem for some operations (open, read, write, seek, close, dir_enum, ioctl) in order to support several FS (unix, smb...)
6. poor management of ejectable devices
7. short/long file name conversion should be consistent (across several processes in the same session, across several sessions)

let's start submitting the new fs code...

basically, you will need to have run this new tool on your configuration directory before we can go any further (otherwise, wine will give you some nice warning messages, and breakages could appear) winefs --config--assign

see the previous winedevel post for some more details.

ChangeLog:

• winefs, a tool for creating the files needed for the new fs infrastructure

New volume management functions from NT

• implementation of Find{First|Next}Volume[AW], FindVolumeClose,
• partial implementation of DeleteVolumeMountPoint[AW], GetVolumeNameForVolumeMountPoint[AW], SetVolumeMountPoint[AW] (only works when mount point is at root)
• rewrite of QueryDosDevice, DefineDosDevice for new fs scheme

Note: DefineDosDevice is now broken (until patch 47)

Changes for device & VxD management (kernel)

• remove server/device.c and all the associated hacks
• opening a device is now implemented as opening a unix file (either a real unix device, or an empty file for VxDs & TSRs)

Notes: server/device.c has to be removed

New scheme for type, label & serial number reading on drives

• rewrote GetDriveType[AW], GetDiskFreeSpace[AW], GetDiskFreeSpaceEx[AW], GetVolumeInformation[AW], SetVolumeLabel[AW], GetLogicalDriveStrings[AW], GetLogicalDrives according to new drive scheme (either from device or from files on hd)
• removed no longer needed part from files/drive.c and include/drive.h

Moved NT => unix path translation to ntdll

• moved path transformation (according to new scheme) into ntdll
• rewrote wine_get_unix_path_name accordingly (and exported it from ntdll)
• rewrote RtlDoesFileExists_U to use these new features

Moved file opening to ntdll

• implementation of NtCreateFile
• modification of server protocol:
  • create_file now uses NtCreateFile parameters (not CreateFile's) as well as NT path names
  • create_named_pipe also uses NT path names
• NtCreateFile can also open directory handles (CreateFile couldn't)
• CreateFile now calls NtCreateFile
• misc. cleanups

Moved directory browsing to ntdll

• Added NtQueryDirectoryFile
• Implemented FindFile{First|Next} on top of NtQueryDirectoryFile

Reviewed directory initialisation & management

• now storing system dirs as full & long path names
• rewrote a bit DIR_SearchPath to use better ntdll functions
• nuked DOS_FULL_NAME structure
• in Win NT mode, no longer remember the per drive current directory
• in Win 9x mode, store per drive current directory in =?: environment variable (? being the drive)

Various clean-ups

• got rid of include/drive.h and include/file.h
• move remaining functions of files/dos_fs.c to dlls/kernel

Note: files/dos_fs.c shall be removed

that's all for now

Here is the detailed TODO in all it's glory. We _really_ need to get this over with, so please help us out to get this release out the door. I'll mark names by the tasks based on conversations I had with folks at WineConf (and on the list). If you notice any mistakes, please let me know. Items marked with (???) have no owner. If you think you can help on any of these (including ones that do have owners!), please let me know. Help is needed and appreciated. If it's not clear what needs to be done for any of these, get in touch with me, I'll be more than happy to help you get started.

Enjoy!

A. WineHQ.org

1. History page (Brian) [IN PROGRESS]
2. Testing status (Ferec) [IN PROGRESS]
3. I18n status (Vincent) [IN PROGRESS]
4. Porting status (Dimi, Steven) [IN PROGRESS]
5. Who's Who (Tom)
6. Documentation page update (???)
7. Download page (esp. source) needs work (???)
8. Acknowledgment page (???)
9. UI status update (???)
10. Integrate API status into WineHQ (???)

B. Documentation

• User Guide
  1. Update configuration instructions based winecfg & regedit (???)
  2. Suggest winefile instead of Calmira (???)
  3. Misc cleanups (Dimi)
• Devel Guide
  1. Update COM section/widl (???)
  2. Redo Multimedia section (???)
  3. Add i18n section (Vincent)
  4. Suggest adding tests w/ patches (Dimi)
  5. Cross compilation on RH (Michael)
  6. Add section on KERNEL32 (???)
  7. Misc cleanups (Dimi)
• Winelib Guide
  1. Update around MinGW/winegcc (Dimi, Francois)
  2. Misc updates (Dimi)

C. Configuration

1. Complete regedit (Attila) [IN PROGRESS]
2. Complete winecfg (Chris, Mike)
3. Setup API .inf scripts (Chris) [IN PROGRESS]

D. UI Code

1. Visible region handling in server (Alexandre)
2. Inter-process handle management (Urlich, Alexandre)

E. File Formats

1. .spec files [DONE]
2. .reg files [DONE]
3. I18n output (Vincent) [IN PROGRESS]

F. Exported API

1. DLL separation I [DONE]
2. DLL separation II (Alexandre, Eric) [IN PROGRESS]
3. wineserver protocol (Alexandre)

G. Tools

1. winebuild: build DLLs from .def files (Alexandre)
2. winegcc: add simple gcc-independence (Dimi)
3. winegcc: generate DLLs/-shared (Dimi)
4. winemaker: generate MinGW compatible makefiles (???)
5. winemaker: use dsw2make from MinGW (???)
6. winemaker: no configure script (???)
7. autoconf: add all Wine-specific macros to the aclocal (???)
8. winedesktop: create new tool (Alex) [IN PROGRESS]

H. Miscellaneous

1. Testing daemon to run as a Windows service (???)
2. Exec-shield support (???)
3. Prelink support (???)
4. Version symbols in libwine & libwine_unicode (Alexandre)
5. Find packager for a PE-build of Wine on SF (???)
6. Standardize Wine handling in autoconf (Dimi)

I. Source Code

1. Move controls/*, windows/* -> dlls/user/ (Alexandre)
2. Move graphics/*, objects/* -> dlls/gdi/ (Alexandre)
3. Move files/*, misc/* -> dlls/kernel/ (Alexandre)
4. Flatten dlls/: msacm/*, msvideo/msrle32, winmm/* (Alexandre)
5. Move documentation/ddraw.txt somewhere (???)
6. Move documentation/samples/generic.ppd -> dlls/wineps (Alexandre)
7. Move documentation/samples/config -> winedefault.reg (???)
8. Move documentation/samples/system.ini -> winedefault.reg (???)

Say, I wanted to thank everyone for coming to Wineconf 2004; as far as I can tell, a good time was had by all, and we may even have accomplished one or two useful things <grin>. I really appreciate that so many of you braved -30C temperature and two days of constant snowfall to come work with us on Wine - such insanity^H^H^H^H^H^H^H^H dedication is admirable.

I wanted to suggest that we get to planning Wineconf 2005 sooner rather than later; I'm curious to see which European city hosts the event <grin>. For the record, we're willing to be the major sponsor for the next Wineconf; we'll kick in some funds and person power to help make sure it happens. However, I think it'll only work well in conjunction with one or more locals.

I did have some closing thoughts and advice I wanted to get off my chest; there are some things I would do differently next time, and it's probably also wise to touch on the things that worked well.

In no particular order, here are a number of thoughts:

1. Screw fancy audio/video streaming.
   Find an inexpensive telephone conference service, and use it. Test it, several weeks in advance, *with the intended audience* (the stream worked fine on this side of the Atlantic, afaict), and *with the expected load*. Our tests were always done with less load than we had during wineconf, because the streaming traffic used the same pipe as the 'net connection everyone was using.
   We wasted a lot of time and energy on this, against my initial better judgement, and it proved to be largely useless, afaict from the #wineconf comments.
   Go low tech. Swallow your geek pride. Just get simple audio that works.
   /me kicks self
2. Things that worked well:
   • An inexpensive location
     Not one person opted for the expensive hotel I listed; cost really matters to this crowd. The last thing we want to do is scare away young people; they often have enormous energy and no cash. Help with hostels and friends with floors was appreciated.
   • Breaks
     The only times that I was sure that productive conversations were occuring was during the breaks. Provide lots of 'em. Go very light on scheduled topics.
   • Do lunch in; that worked really well.
     Have lots of food and beverages about, that also seems to work well. Bring the water cooler down on the *first* day <grin>.
   • Internet connectivity is a must. Really.
     And provide both wireless and wired. We had some grumpy campers when we initially didn't have enough cat5 ports.
   • All of the professional conference paraphenalia was invaluable. A wireless mic (preferably two) and someone to operate it. A PA type system. A projector. Even with the relatively small group we had it was invaluable.
3. Suggestion - blue collar location
   I know it's fashionable to suggest fancy vacation spots for Wineconf 2005, but I honestly think it would be much better to pick a 'blue collar' venue. Pick somewhere that is a transportation hub, with modest prices. Someplace where some Wine hackers live; having local help is incredibly valuable (thanks to Mandi, Chris, Jon, Aric, Zak, Newman, and all of the gang who did so much work).
   In fact, when we did go to the fancy tourist night spot, we ended up at a bar where it was too loud to talk; conversation amongst folks from 10 different countries is hard enough without load blaring music or odd ball distractions.
   A quite room and a good supply of ale, perhaps with a whiteboard, is what folks mostly craved.
   This is just my $0.02; I think others would differ sharply.
4. The final, critical piece of advice
   Don't type 'ifconfig eth0 down' in a terminal Window on the Mac in an attempt to reinitialize it's DHCP settings, unless you're dead certain you haven't ssh'd over to the server that is the life blood of your community, and is physically miles away behind locked doors...
   ...and I still can't figure out why Alexandre won't take my patches! <grin>

At any rate, I feel much better now - thanks for listening, and thanks for coming.

One of the action items decided on at wineconf was to set up an IRC channel for Wine developers. This channel now exists and is #winehackers. Key points to be aware of are:

• It's on freenode
• It is for developers only, user tech support (how do i run counterstrike?) etc should be/will be bounced to #winehq
• There are a lot of ops. This is intentional. Often on #winehq there are problems caused by users but there are no ops around (only like 3 guys have op access to it). Me (TD), Mike McCormack (mike_m) and Francois Gouget (fgouget) have the ability to add people to the auto-op list through virtue of being the first guys into the channel.
• The channel is modelled after #gnome-hackers on gimpnet, which has been a great success with buy-in from even their busiest, most core hackers (hint hint alexandre :)
• All wine hackers are welcome, this most explicitly includes WineX dudes
• No topic is offtopic.

Have fun! I'll submit a patch to add mention of it to the WineHQ website, but #gnome-hackers grew to a huge number of people just through word of mouth so there's no real hurry. Tell your friends, rescue budding wine hackers from the helpdesk that is #winehq etc. It's a resource that is there to be used, so use it.

I'm trying to find a file copy tool which works on windows as well as wine. I tried several and this looked promising:

ftp://ftp.simtel.net/pub/simtelnet/msdos/fileutil/cc108dos.zip

On Windows it copied all files without problems and kept the long filenames even if the name implies that it's DOS-only, but it worked fine on W2K. But on wine the long names where all shortened to something like CINO~E2H.CPP. So it doesn't look like normal DOS short names ...~1.cpp but it's not the long name either. Can anybody try this out?

My wine (actual cvs) config is set to windows version nt40.

It's the short names Wine makes when there is no DOS short name (i.e. when you're not on a VFAT partition).

Try win95. Wine currently only emulates the DOS long file name API on win9x, since it did not exist on nt4.

No, you couldn't get long file names in DOS programs under NT4. Try to run command.com (a DOS app) instead of cmd.exe (a Win32 console app) under NT4 sometime. NT4 had generally poor DOS support, mostly because its kernel was not DOS; Win95 had much better DOS support because of its DOS-based kernel, and that kernel provided long file name services to DOS programs running under it (on a VFAT partition).

Now it's possible that 2000 and XP added Win95-compatible long file name services for DOS programs, in which case the version check in Wine for the LFN DOS API could be updated. The version check is anyway (probably) mostly there to prevent winver=win311 from enabling the LFN API.