World Wine News

The aim of this project is to provide an Integrated Development Environment for MinGW compiler. (Minimalist GNU for Windows)

Development started during July 2001 with following goals :

1. Provide a "Minimalist" Open Source IDE, developed with nothing more than itself and built with MinGW compiler.
2. Make it as small and fast as possible, using only Windows APIs.
3. Make it easy to use for beginners and as powerful as possible for advanced users.
4. Specialize one module of its code for simple and reusable C++ objects that will provide ready to use application skeletons. A quickly way to create a dialog box, SDI or MDI based project.
5. Provide simple, but original features like creating archives, copying these to a floppy disk or uploading to a server in a few mouse clicks. Make use and promote Open Source command line tools.

I got around getting Visual-MinGW to compile under Winelib. This patch touches only your makefile, and I hope the changes are not controversial:

• Use forward slash instead of backslash
• Explicitly list the DLLs you link against (shell32, comdlg32, advapi32)
• It make sense to specify -mno-cygwin For some reason, the code seems to require it. Please check that it works under Windows as well. If it does, if makes sense to have it as Visual-MinGW should not have a dependency on Cygwin, as far as I can tell.
• Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag.
• Do not use -fvtable-thunks, it is deprecated in gcc 3.2

Please apply this patch with 'patch -p1 < winelib.diff'.

Note that I still need to get some changes integrated into the official Wine tree before you can actually compile Visual-MinGW under Winelib. The changes are not controversial, and I hope to get them in real soon. I will let you know when that happens.

Regardless, I think the changes I'm proposing are logical in and of themselves, so I figured they can be integrated regardless.

makefiles are generated by Visual-MinGW, so I suggest to add dedicated makefiles for Winelib. eg: "makefile.wine".

That way, makefiles for Winelib won't be overwritten by Visual-MinGW, and it will be more convenient to do some changes in these.

this patch starts splitting code between ntdll and kernel32:

• it uses a module description structure closer to what NT does (our WINE_MODREF makes heavy use of it, even if all of it isn't done (filenames, list management for example))
• it cleans a bit calls between ntdll/kernel32 when possible

however, it doesn't move the code to kernel32 (there are still quite a few pending dependencies)

since I'm not sure Alexandre will apply it right away (it seems his mailbox is ready to explode ;-)), please give it a try (I've been using it for a few days without noticeable glitches, but since it tackles wine at heart, heavy testing would be better)

for the ones of you who would like to go further with it, I put #define (_NTSYSTEM_ and _KERNEL32_ to mark where the functions belong to) The final scheme should be (even if it's not achievable today):

in ntdll
loader/elf.c
loader/loadorder.c
loader/module.c (the part marked _NTSYSTEM_)
loader/pe_image.c
loader/pe_resource.c
in kernel32
loader/module.c (the part marked _KERNEL32_)
loader/ne/convert.c
loader/ne/module.c
loader/ne/resource.c
loader/ne/segment.c
loader/resource.c
loader/task.c

what's still missing:

• process & thread management (esp. creation) needs to be properly separated
• some ntdll internal calls (GetModuleFileName for example) needs to be rewritten
• include/module.h should go,
  • for the Ldr* (and all ntdll related stuff) to include/ldr.h (BTW, I'm not sure of this, could someone with a recent NT DDK check this)
  • for the NE/16 bit part to include/wine (we could even make it cleaner by implementing a real VDM support in wine, but that's another story)
• separation of loader/pe_resource & implementation of resource enumeration in ntdll
• proper fixes for a zillion of regressions

I'm trying to figure out why an app works on Windows but not Wine, and it'd sure be nice to be able to log all the api calls the app makes under each of the two environments; then perhaps I could compare the logs to see where Wine differed from Windows.

Does anyone else do stuff like that? If so, what tools do you use?

http://www.wheaty.net/FAQ.htm#APISPY32 says that the best tool out there is http://www.internals.com/utilities_main.htm (Supposedly the author will send source to you on request, too.) That program requires a text file containing the prototype for each API you want to spy on, though, and it only comes with 3 APIs as an example. Does anyone have a full version of that file, or a perl script to create it from the wine tree?

I suppose I could write my own, too, if that's the only way to get a tool that works well in both environments. http://help.madshi.net/ApiHookingMethods.htm seems to have lots of info on that.

We've looked into this extensively; looking at both flavors of apispy (yes, there are two of them, with very similar names), and a lot of other variations.

However, I've got a half baked W2K based solution similar to the Detours library from Microsoft. The advantage to my approach is that it generates a relay log identical to that of Wine, which then allows for diffing the log files.

*I* think it would be wicked cool. Sadly, most of the Wine gurus I work with just shake their head and smile whenever I suggest it deserves priority.

Debugging Tools for Windows http://www.microsoft.com/ddk/debugging has logger.exe/logviewer.exe which help a lot in investigating what actually windows applications do. Logger creates binary log files which logviewer is able to parse/view. Even there is a mechanism to extend the logging facility by simply editing a .h like files.

Logviewer is able to show all the API arguments, various data structures, API results and more. It can export log into the plain text file, which could be diffed against another one. I would say that log file is *very* similar to the Wine relay log. Just give it a try.

You could look at : http://www.dxspy.com/

For hooks : http://www.codeproject.com/system/hooksys.asp

I am interested in support for file-locking and locking of specified regions of a file, in order to support databases such as MS-Access and Paradox.

But as I ponder the various likely-looking segments of the source-code, I really do not know where to begin ... nor what has been done in this area before.

It is clear that an implementation of locking must work on SMB-shares and that it should "actually lock things" in that other Windows users should see the locks as they are placed and removed. It's also clear that implementing timeouts on these locks could be "problematic," since the Unix impl. of file locking is not quite the same as Windows expects.

Pointers? Comments? War-stories? Advice? "Someone already did that"s?

Basically much of it has been done before but hasn't made it to the CVS. Way back, Alexandre Julliard implemented it in the Corel source tree. Back in November 2001 I tried reworking the code to fit into the current tree and submitted it (with a few bugs I am sure) but it was not accepted. Alexandre had it on his list of things to do but I don't know where it stands currently.

If you do intend working on it then you are going to have to address some of the following issues:

1. Windows region locking has different behaviour with regard to merging regions etc. than Unix.
2. Remember that fcntl locks are on the actual file, not on the handle; and closing one handle drops all the locks on all other handles to the same file. (I am being almost criminally lax with my wording here but it will do for now).
3. The timeouts are going to be an interesting task. However the structure of the wine server should help immensely
4. To the best of my knowledge SMB file systems don't handle it. No one has yet told me differenly on the several occasions I have tried to ask. (I know that Samba serves out locks to Windows machines successfully but if you put an fcntl lock on a file on a SMB share to the best of my knowledge it doesn't translate to an SMB lock request).
5. The whole issue of advisory and mandatory locking.

Our software depends quite significantly on region locking but we don't need the full semantics and we can make guarantees such as only one handle open on a file by a process so what we have done is to use winelib and create builtin dlls for our own ones but that use the native fcntl locking.

Ah, yes, file locking. I was one of the folks who advised Sun as they were bringing file locking to Java (in "JSR-51"), and we had some fun discussions about how to define file locking in Java so it would map properly onto either Windows or Unix.

One thing I recall is that W. Richard Stevens has a nice discussion of Unix locking in chapter 12 of "Advanced Programming in the Unix environment", published 1993. It aged fairly well, I think, and provides a bit of insight into how locking evolved -- and some problems with mandatory locking (e.g. mandatory locking didn't prevent ed from editing a file!) Note that mandatory locking is not part of Posix ( http://www.opengroup.org/onlinepubs/007904975/toc.htm ).

JSR-51 decided to map Java file locks to mandatory locks on Windows, and advisory locks on Unix. I'm afraid that's about the only real option.

It sounds to me like the file-locking code I am looking for has "already been done" and/or "was rejected" at some time in the past.

I'm probably not the best qualified to do this if it has already been done.

But in order to run databases on Wine, I need it.

I am trying to follow this discription on how to compile win32 source code with the winelib ( http://www.winehq.org/docs/winelib-guide/winelib-toolkit#WINEMAKER )

The process generates a Makefile that is supposed to complie a resource file e.g. winemine.rc with the wrc compiler, but winemaker adds a '-L' option to the wrc compilwr that is does not recognize.

I am using wine-20021219 on RedHat 8.0.

It seems like a bug in winemaker.

I have changed this line in the Makefile

## WRCFLAGS = -r -L
WRCFLAGS = -r

and it compiles.

(/user/usr/local/wine/programs/winemine-hcs) #./winemine-hcs
/usr/local/bin/wine: cannot find 'winemine-hcs.exe'

It still cannot find 'winemine-hcs.exe'. What seems to comes nearest is

-rwxr-xr-x 969 jan 1 21:00 winemine-hcs
-rwxrwxr-x 793446 jan 1 21:00 winemine-hcs.so
-rw-rw-r-- 44160 jan 1 21:00 winemine-hcs.spec.c
-rw-rw-r-- 92648 jan 1 21:00 winemine-hcs.spec.o
-rw-rw-r-- 173 jan 1 20:59 winemine.exe.dbg.c
-rw-rw-r-- 2040 jan 1 21:00 winemine.exe.dbg.o
-rw-rw-r-- 43665 jan 1 15:39 winemine.exe.spec.c

I sure hope someone can help out - because I plan to try to see if I can make some of those 7.000 win32 applications over at sourceforge.net compile under winelib.

Currently execname.so is being created rather than execname.exe.so. The patch I submitted a few hours ago (don't know if it has made it through yet) includes a fix for this.

Copying the file is actually what I did for several weeks, rather than dig in to winemaker to fix the problem. But I get fed up and started putting together a patch for this several days ago. So now it is ready to roll. Good timing, yes?

Visual-MinGW uses the following:

visual-mingw ICON Mainicon.ico

which apparently windres accepts, but fails with wrc because of the '-' in 'visual-mingw'. Can someone please check if it works with the MS tools, to determine if we need to fix wrc? Tnx.

I knew that strings like "x-x!xx" were accepted.

I just tested icon resource beginning with weird characters like "!icon" or "-icon" and that works (tested under VC++/sp5).