5 ms·
How do Win 3.1 applications work in Wine?
- chris_wot 11y agoWow! Seems like an elegant solution. Does this work on architectures other than x86?
- pavlov 11y agoThere'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.
- agumonkey 11y agoIt'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/ 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)
- mastax 11y ago> 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.
- agumonkey 11y agoI've heard that too. let's have a list :)
- beefhash 11y ago> ps: I'd love to see other beautiful C codebases. (ZFS ain't bad) See also: https://news.ycombinator.com/item?id=11005003 https://news.ycombinator.com/item?id=11005003 -- It's not only C, but there are some C codebases on there.
- agumonkey 11y agoThanks, lots of good things there :)
- gecko 11y agoI 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.)
- pavlov 11y agoYeah, 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.
- wmil 11y agoAlthough types in _t are supposed to be reserved for future POSIX / compiler use.
- cmrdporcupine 11y agoInterestingly 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.
- mfincham 11y agoCould you link the GEM sources? I used GEM a long time ago and would love to have a look.
- 11y ago
- maxxxxx 11y agoUpper case names like MCIWNDM_SETTIMEFORMATA are constants. Once you work with it a little it makes complete sense.
- deleted 11y ago[deleted]
- dezgeg 11y agoUpper case names are used for both; HWND, UINT, WPARAM, LPARAM, ULONG_PTR in that example are typedefs.
- jcoby 11y agoThat'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/ https://blogs.msdn.microsoft.com/oldnewthing/
- therein 11y agoOh 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.
- to3m 11y agoReally? Have you ever done any professional C work? :) This is, like, #99 on the list of problems. #99... out of 50!
- shmerl 11y agoInterestingly, 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-for-16-bit-Windows-Applications-447273.shtml http://news.softpedia.com/news/Linux-Kernel-3-14-Breaks-Wine... https://bugs.winehq.org/show_bug.cgi?id=36664 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.
- TazeTSchnitzel 11y agoSome of the apps included in Windows 95 were 16-bit, for performance or because they didn't have time to update them.
- jawngee 11y agoA 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".
- rossy 11y agoI 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.
- 0x0 11y agoThe 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.
- TazeTSchnitzel 11y agoOh, 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.