WineHQ

World Wine News

All the news that fits, we print.

02/13/2004
by Brian Vincent
Issue: 210

XML source
More Issues...

This is the 210th issue of the Wine Weekly News publication. Its main goal is to revel in Purgatory It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org


This week, 183 posts consumed 522 K. There were 65 different contributors. 29 (44%) posted more than once. 30 (46%) posted last week too.

The top 5 posters of the week were:

  1. 26 posts in 69K by Dimitrie O. Paun
  2. 13 posts in 31K by Alexandre Julliard
  3. 12 posts in 42K by Mike Hearn
  4. 10 posts in 37K by Fabian Cenedese
  5. 7 posts in 17K by Mike McCormack

News: Wine20040213, PR 02/07/2004 Archive
News

Alexandre released Wine-20040213 on Friday. The announcement noted the following changes:

WHAT'S NEW with Wine-20040213: (see ChangeLog for details)

  • Improved support for screen resolution changes.
  • More shell32 improvements.
  • Several Winelib compatibility fixes.
  • Beginnings of support for typelib creation.
  • Lots of bug fixes.

Go to SourceForge to download the latest release.

Looks like while I was on vacation we got Slashdotted .

Also found this week was a short review of Xandros 2.0 Deluxe. Normally I skip over such short reviews, especially ones that barely discuss Windows' compatibility. What's interesting about this one is it seems to have appeared in dead tree format on newstands.


Prelinking and Exec Shield Problems 02/13/2004 Archive
Memory Management

One problem on the radar screen deals with supporting two new Linux-isms: exec shield and prelinking. Exec shield is a security mechanism to prevent overflows from being exploited. It relies on changing the memory layout of an executable... unfortunately Wine requires a very particular layout. Prelinking is a method to speed up application startup time by having a preferred memory layout. Mike Hearn started thinking about how to solve these problems and posted a proof-of-concept to wine-devel. Below he also describes exactly what problems Wine faces and how he solved them:

Attached is a prototype of a technique we can use to solve the problems caused by exec-shield and prelink. Yes, it's complicated. I wish it wasn't, but simpler attempts at this haven't worked. I can't think of another way to do it, given my limited knowledge. It's possible Alexandre can figure something out, but as that hasn't happened yet here is my contribution.

This is not useful inside Wine. It's a prototype only - it requires a C99 compiler, the code is a mess, and all it shows is the loader app running "target" which just prints out the mappings. Some more work would be needed to turn this into a patch, but I don't know when I'll get time to do this, so here is my work for others to pick up the baton if they want to.

You can see if it's working by ensuring there is only one /dev/zero entry every time when exec-shield-randomize is on. When it is on, the output of "loader" should be different each time, use diff to see this. When exec-shield is off, there should be no differences.

Prelink has the same effect but the addresses are randomized in a cron job, not on every program load.

Don't worry if you don't fully understand this code, neither do I ;) It's some pretty hardcore voodoo, at least by my standards.....

Here is the README contained within:

Mike Hearn

  • OK, so what is this? This is a prototype of some code that will allow us to solve the problems exec-shield and prelink are giving Wine. They stop us working because they randomize the load addresses of DSOs, so any linux libraries we link against might get dropped in the middle of the load area we need. This is Bad News. By default EXE files on Windows have their relocation records stripped (to save space). They must be loaded at 0x400000. Because an EXE is always the first thing into an address space, this is no problem. Unfortunately on Wine of course the EXE isn't the first thing into memory - Wine is. Basically, the problem is that the dynamic linker thinks we have a clear and empty address space. In fact we don't, we want a specific region reserved for later use. The dynamic linker (rtld or "elf interpreter") is the first thing that runs in a dynamically linked binary, so we have a problem. Wine doesn't get control until the damage is already done.
  • How does it work?
    We have a stub binary, the preloader, which is statically linked. It gets control direct from the kernel, and the rtld isn't run.
    We mmap the PE load area, with the MAP_FIXED (so we grab the exact range of addresses we need) and MAP_NORESERVE (so we don't try and allocate the memory, which is what scuppered earlier attempts to fix the issue).
    That's the easy part. It's, what, 4 lines of code? Nothing. It's piffling. The hard part, which is what takes up the other 320 lines of code is restarting the standard boot process. We must do what the kernel would normally do - map in the target (wine-pthread/kthread), relocate the sections to the right place, set up the entry stack for the ELF interpreter and then jump into it in order to convert our static binary, into a dynamic one.
    Once we reach the other side of the dynamic linker rollercoaster, we can then unmap the load area and tada! we now have a space we can map PE binaries into.
    This works, for a simple target binary. Will it work once we start throwing more complex stuff (TLS initialization etc)? I just don't know. Only time will tell. I expect so, but there's no way to be 100% sure. This sort of stuff is simply not done anywhere else.
  • Did you really write this all yourself?
    Nope, I was aided by the sources to ul_exec (BSD licensed): http://lists.netsys.com/pipermail/full-disclosure/2004-January/015143.html
    The rtld and kernel sources were valuable references but I didn't use any code from them.
  • How portable is it?
    I only tested this on Linux. The problem only manifests itself on Linux - other UNIXy platforms don't have technologies like exec-shield (for security) or prelink (for speed), so it's not a problem there. It's possible they will develop them in future though, so portability is still a concern.
    In theory it's 100% portable. ELF is a standard, and even though it embedded asm and such, it should still work. MAP_NORESERVE *might* be a GNU extension, I'm not sure, but I don't think it is. We can't work reliably without this flag anyway so it's a moot point.


Darwine Update 02/12/2004 Archive
Status Updates

The Darwine team had another release on their port to Mac OS X. Their biggest to-do item right now seems to be integrating an x86 emulator so they can actually run Windows programs out of the box. Sanjay Connare provided an update:

I have updated Darwine binary to version 1.06 and it is being released as a Developer Preview. It does not yet support the running of x86 exe's, however we are begging to work on this feature. The binary should be downloaded from either the home page link here

or the projects file release page here

to insure that the latest version is being used.

The binary requires Mac OS X 10.3 or higher and for the X11 SDK to be installed. The new installer checks for these before installs, fixes a numerous amount of bugs, including installation of default configuration that were present with the first release and now includes the wine headers.


Crypto and RSABASE.DLL 02/13/2004 Archive
Integration

Mike McCormack stubbed out a new DLL, This patch allows Steam to login. It also provides a framework for implementing the rest of rsabase.dll correctly using libcrypto.so

Geoff Thorpe thought it might be a good way to get involved, Cool, I've been looking for an excuse to do something useful on Wine, and as one of the developers of libcrypto.so (www.openssl.org) perhaps this might be the place? Does anyone have good refs/links to the corresponding win32 side of this?

Mike had some pointers:

Having a look at the documentation for the CP* functions on MSDN would be a good start.

The next thing to do would be to write your own test program that works in Windows, and uses those functions. Maybe just start by encrypting a few bytes, then check they're encrypted right, then decrypting them again, and checking they come out to the right thing.

Once your test program works on Windows, run it in Wine, and start implementing FIXMEs.

It looks like the CryptXxxx functions are wrappers for each dll's CPXxxx functions... eg. ADVAPI32's CryptGenRandom() calls to the CPGenRandom() function in the crypt provider's DLL.


Making Better Icons 02/09/2004 Archive
Graphics

Terry Scott offered to improve Wine's icons but needed some help getting started, I'm an illustrator who has been working in the Web Designing/Programming world for a while and would like to help out with drawing icons for Wine. Is there a list of what needs to be drawn and who to send the icons to?

Dimi explained the process and exactly what the files are:

Perfect! We need a guy like you on the team, we're not that graphically inclined :)

There is no official list of things that need work. But you can try by reviewing what we already have in there, and see what needs love (I'm sure you'll find stuff < g >).

Here are the list of icons: (Please note that to get these you'll need to build wine. These resources are not included "as is" in the code, rather they are hex encoded as text in resource files (.rc). The build process extracts them from there into the files listed below, via a tool of ours (tools/bin2res). If you modify these extracted files, this same tool can be later used to encode them back into the .rc files where they belong. Once there, you can just create a regular patch and send it over to wine-patches_at_winehq.org for inclusion into the tree)

    ./dlls/commdlg/cdrom.ico
    ./dlls/commdlg/floppy.ico
    ./dlls/commdlg/folder2.ico
    ./dlls/commdlg/folder.ico
    ./dlls/commdlg/hdisk.ico
    ./dlls/commdlg/network.ico
    ./dlls/commdlg/pd32_collate.ico
    ./dlls/commdlg/pd32_landscape.ico
    ./dlls/commdlg/pd32_nocollate.ico
    ./dlls/commdlg/pd32_portrait.ico
    ./dlls/shell32/desktop.ico
    ./dlls/shell32/document.ico
    ./dlls/shell32/drive.ico
    ./dlls/shell32/folder.ico
    ./dlls/shell32/folder_open.ico
    ./dlls/shell32/mycomputer.ico
    ./dlls/shell32/000.ico
    ./dlls/shell32/003.ico
    ./dlls/shell32/004.ico
    ./dlls/shell32/008.ico
    ./dlls/shell32/015.ico
    ./dlls/shell32/034.ico
    ./dlls/user/resources/oic_bang.ico
    ./dlls/user/resources/oic_hand.ico
    ./dlls/user/resources/oic_note.ico
    ./dlls/user/resources/oic_ques.ico
    ./dlls/user/resources/oic_sample.ico
    ./dlls/user/resources/oic_winlogo.ico
    ./dlls/user/oic_bang.ico
    ./dlls/user/oic_hand.ico
    ./dlls/user/oic_note.ico
    ./dlls/user/oic_ques.ico
    ./dlls/user/oic_sample.ico
    ./dlls/user/oic_winlogo.ico
    ./programs/cmdlgtst/about.ico
    ./programs/uninstaller/uninstaller.ico
    ./programs/wcmd/wcmd.ico
    ./programs/winefile/winefile.ico
    ./programs/winemine/winemine.ico

And the list of bitmaps:

    ./dlls/comctl32/idb_hist_large.bmp
    ./dlls/comctl32/idb_hist_small.bmp
    ./dlls/comctl32/idb_std_large.bmp
    ./dlls/comctl32/idb_view_large.bmp
    ./dlls/comctl32/idb_view_small.bmp
    ./dlls/commdlg/800.bmp
    ./dlls/commdlg/fontpics.bmp
    ./dlls/user/resources/obm_btncorners.bmp
    ./dlls/user/resources/obm_btsize.bmp
    ./dlls/user/resources/obm_check.bmp
    ./dlls/user/resources/obm_checkboxes.bmp
    ./dlls/user/resources/obm_close.bmp
    ./dlls/user/resources/obm_combo.bmp
    ./dlls/user/resources/obm_dnarrow.bmp
    ./dlls/user/resources/obm_dnarrowd.bmp
    ./dlls/user/resources/obm_dnarrowi.bmp
    ./dlls/user/resources/obm_lfarrow.bmp
    ./dlls/user/resources/obm_lfarrowd.bmp
    ./dlls/user/resources/obm_lfarrowi.bmp
    ./dlls/user/resources/obm_mnarrow.bmp
    ./dlls/user/resources/obm_old_close.bmp
    ./dlls/user/resources/obm_old_dnarrow.bmp
    ./dlls/user/resources/obm_old_lfarrow.bmp
    ./dlls/user/resources/obm_old_reduce.bmp
    ./dlls/user/resources/obm_old_restore.bmp
    ./dlls/user/resources/obm_old_rgarrow.bmp
    ./dlls/user/resources/obm_old_uparrow.bmp
    ./dlls/user/resources/obm_old_zoom.bmp
    ./dlls/user/resources/obm_reduce.bmp
    ./dlls/user/resources/obm_reduced.bmp
    ./dlls/user/resources/obm_restore.bmp
    ./dlls/user/resources/obm_restored.bmp
    ./dlls/user/resources/obm_rgarrow.bmp
    ./dlls/user/resources/obm_rgarrowd.bmp
    ./dlls/user/resources/obm_rgarrowi.bmp
    ./dlls/user/resources/obm_size.bmp
    ./dlls/user/resources/obm_trtype.bmp
    ./dlls/user/resources/obm_uparrow.bmp
    ./dlls/user/resources/obm_uparrowd.bmp
    ./dlls/user/resources/obm_uparrowi.bmp
    ./dlls/user/resources/obm_zoom.bmp
    ./dlls/user/resources/obm_zoomd.bmp
    ./dlls/user/obm_btncorners.bmp
    ./dlls/user/obm_btsize.bmp
    ./dlls/user/obm_check.bmp
    ./dlls/user/obm_checkboxes.bmp
    ./dlls/user/obm_close.bmp
    ./dlls/user/obm_combo.bmp
    ./dlls/user/obm_dnarrow.bmp
    ./dlls/user/obm_dnarrowd.bmp
    ./dlls/user/obm_dnarrowi.bmp
    ./dlls/user/obm_lfarrow.bmp
    ./dlls/user/obm_lfarrowd.bmp
    ./dlls/user/obm_lfarrowi.bmp
    ./dlls/user/obm_mnarrow.bmp
    ./dlls/user/obm_old_close.bmp
    ./dlls/user/obm_old_dnarrow.bmp
    ./dlls/user/obm_old_lfarrow.bmp
    ./dlls/user/obm_old_reduce.bmp
    ./dlls/user/obm_old_restore.bmp
    ./dlls/user/obm_old_rgarrow.bmp
    ./dlls/user/obm_old_uparrow.bmp
    ./dlls/user/obm_old_zoom.bmp
    ./dlls/user/obm_reduce.bmp
    ./dlls/user/obm_reduced.bmp
    ./dlls/user/obm_restore.bmp
    ./dlls/user/obm_restored.bmp
    ./dlls/user/obm_rgarrow.bmp
    ./dlls/user/obm_rgarrowd.bmp
    ./dlls/user/obm_rgarrowi.bmp
    ./dlls/user/obm_size.bmp
    ./dlls/user/obm_trtype.bmp
    ./dlls/user/obm_uparrow.bmp
    ./dlls/user/obm_uparrowd.bmp
    ./dlls/user/obm_uparrowi.bmp
    ./dlls/user/obm_zoom.bmp
    ./dlls/user/obm_zoomd.bmp
    ./programs/regedit/folder1.bmp
    ./programs/regedit/folder2.bmp
    ./programs/regedit/folder3.bmp
    ./programs/winecfg/idb_wine.bmp
    ./programs/winefile/drivebar.bmp
    ./programs/winefile/images.bmp
    ./programs/winefile/toolbar.bmp
    ./programs/winemine/faces.bmp
    ./programs/winemine/leds.bmp
    ./programs/winemine/mines.bmp

Anyone wanting to help Terry may want to contact him, his email address is on his original post .


VisualAge Smalltalk as a Test Program 02/10/2004 Archive
Testing

Someone wrote to the list to give mention a good program to test Wine with:

I find the following program to be an excellent test program for anything that acts like Windows. The program is Vast and may be downloaded from http://www-306.ibm.com/software/awdtools/smalltalk/ . The program you want is the 6.0.2 fixpack which is also a fully operational evaluation version of Vast. It gives an evaluation notice on startup but is not disabled and has no timeout. The value of this program is that it runs on everything from Win 95 on and uses just about every feature in a Windows system. It is one of the best tests of system integrity I have been able to find. It almost installs and runs on Wine.

Vast is IBM's "VisualAge Smalltalk".


All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.