How do Win 3.1 applications work in Wine? | Hacker News Reader

How do Win 3.1 applications work in Wine?

wine-staging.com

94 pointspantalaimon28 comments

Interestingly, even some Windows 95 applications require 16 bit support. For instance The Neverhood. Linux had a regression when it stopped working at tome point (which is now fixed):

http://news.softpedia.com/news/Linux-Kernel-3-14-Breaks-Wine...

https://bugs.winehq.org/show_bug.cgi?id=36664

Not that it matters much anyway, since The Neverhood works in ScummVM now. But in practice Wine now better supports such application than any recent Windows itself.

A lot of media apps in Windows 95 need to thunk down to 16-bits for solid, interrupt driven timing that wasn't possible in 32-bits without shipping a "device driver".

Some of the apps included in Windows 95 were 16-bit, for performance or because they didn't have time to update them.

Interesting. I always found it that i wanted to the run old apps on WINE. Imagine running Phone Dialer on WINE and making a call

Most of them were really 32-bit, but still required 16-bit support for certain components.

There's something about Win32's C style that just makes my eyes bleed:

  static LRESULT WINAPI MCIWndProc16(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
  {
    switch (msg)
    {
    case MCIWNDM_SENDSTRINGA:
        lparam = (ULONG_PTR)MapSL(lparam);
        break;

    case MCIWNDM_SETTIMEFORMATA:
        lparam = (ULONG_PTR)MapSL(lparam);
  ...

All caps for typedefs in C is just evil. And this example doesn't even have Hungarian notation.

That's not even the full Win32/16 style. That first line should be:

    static LRESULT WINAPI MCIWndProc16(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

And even then MS couldn't decide whether to use message (MSG struct), Msg (SendMessage), uMsg (WindowProc) for the second variable name. Sometimes they would use hwnd as well. I remember it all being very, very confusing when I was learning to program because it was inconsistent in so many ways.

In a semi-related note, Raymond Chen's blog (1) is great for diving into the history of the Windows API and its many quirks and gotchas.

[1] https://blogs.msdn.microsoft.com/oldnewthing/

Oh my god, I had the same experience growing up. Whenever I moved into the Windows API territory as a kid, I got pushed away, and now in hindsight I know why. The data types used to communicate with the Windows API was ambiguous, sometimes interchangable and often were simply typedefs that I didn't know about. Terribly confusing to a child but now I understand the concept of backwards compatibility and why one would avoid breaking support.

I get why you say they're evil, but their existence meant that moving from Win16 to Win32 to Win64 with minimal code changes was actually feasible without major rewrites. If those had instead been e.g. "static pascal MCIWndProc16(unsigned, unsigned, unsigned, long)", then you'd have had issues with some of those transitions. (In fact, you kind of did going from 32 to 64 bit, which is why "long" in Win64 is still 32 bits.)

Yeah, they were useful all right! I was just doing some petty complaining about why they chose that particular style.

Everybody else uses either camelcase or snakecase for C types, so a type used to transmit information about zombie bites would be something like ZombieBiteDescriptorRef or zombie_bite_desc_t ...

But on Windows, the type would be ZOMBIEBITEDESCRIPTOR. And typically a variable's name would be prefixed with the type, Hungarian notation style:

   ZOMBIEBITEDESCRIPTOR *pzbdFreshBite = WDGetLatestBiteEx(0, 0, NULL, NULL, 0);
   ...

It just looks so bad when you're used to the other C styles.

Interestingly I found that the (now GPL'd) GEM sources from Digital Research (windowing system from the 80s for x86 and 68k) also follows this capitalized-typedef convention. It's all WORD/LONG/UWORD. They even typedef void to VOID.

It's excruciating on my eyes.

Could you link the GEM sources? I used GEM a long time ago and would love to have a look.

The DR GEM sources are here:

http://www.deltasoft.com/downloads-gemworld.htm

The actively developed fork of it for the Atari ST and emulators is here: http://emutos.sourceforge.net/en/

Although types in _t are supposed to be reserved for future POSIX / compiler use.

It's doubly sad when you think that most people will see this first. I understand that's a complex and real product so to hell with idealism, but when you see code like:

http://piumarta.com/software/maru/

it makes C much more loveable.

ps: I'd love to see other beautiful C codebases. (ZFS ain't bad)

> ps: I'd love to see other beautiful C codebases. (ZFS ain't bad)

See also: https://news.ycombinator.com/item?id=11005003 -- It's not only C, but there are some C codebases on there.

Thanks, lots of good things there :)

> ps: I'd love to see other beautiful C codebases. (ZFS ain't bad)

This is not my area of expertise, but Lua, LuaJIT, and Redis are quite nice imo.

I've heard that too. let's have a list :)

Really? Have you ever done any professional C work? :)

This is, like, #99 on the list of problems. #99... out of 50!

Upper case names like MCIWNDM_SETTIMEFORMATA are constants. Once you work with it a little it makes complete sense.

Upper case names are used for both; HWND, UINT, WPARAM, LPARAM, ULONG_PTR in that example are typedefs.

The most interesting takeaway here is perhaps that wine manages to run win16 in x86-64 mode, something that even microsoft gave up on in their 64bit windows releases.

Oh, Microsoft could have done it, they just didn't want to. And that was hardly an unreasonable decision: 16-bit apps were basically only being used for installers by the time of Vista.

I didn't know it was common for operating systems to let user-mode code adjust the memory segments and for them to persist those changes between context switches. It seems like a pretty niche feature to have in a 64-bit operating system, though I'm glad it's there. I only recently tried to run a 16-bit program in Wine on a 64-bit machine and I was pleasantly surprised to see it work perfectly.

Wow! Seems like an elegant solution. Does this work on architectures other than x86?

I think it works perfectly on all architectures capable of executing 16-bit x86 code :)

Yeah, dumb question :-)

Reply on news.ycombinator.com