5 ms·

sp2tab.bat which calls tabify.sed to replace spaces with tabs. Nice to know that some things never change. Edit: Also a 16bit windows executable version of G

by dsp1234 10y ago

sp2tab.bat which calls tabify.sed to replace spaces with tabs. Nice to know that some things never change. Edit: Also a 16bit windows executable version of GREP, just tested on a 32bit version of Windows and it still works (but not on 64bit)

umanwizard 10y ago
Unfortunately no 16-bit Windows executables work on 64 bit, since x86-64 processors lack the ability to run in 16-bit mode.
- derefr 10y ago
  I keep seeing this statement, and it's making me wonder: how hard would it have been for Windows 10 to simply ship with a 16-bit WinAPI-binary transpiler (ala Rosetta) or emulator (ala DOSBox)?
  - raverbashing 10y ago
    There was something called WoW, not sure it did that But at this point I can see why MS would not bother with it
    - mishac 10y ago
      IIRC WoW just provided a layer to point 32bit binaries to 32bit libraries on 64bit systems. So you have the ass-backwards situation where %WINDIR%\System32 is full of 64bit dlls, and %WINDIR\SysWOW64 is full of 32bit dlls.
      - akira2501 10y ago
        In traditional Microsoft fashion, it's both [0]. WoW is the 16bit compatibility layer on 32bit systems, WoW64 is the 32bit compatibility layer on 64bit systems. [0]: https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
      - blakeyrat 10y ago
        The original WOW was doing a 16-bit to 32-bit layer. WOW64 (in 64-bit Windows OSes) does 32-bit to 64-bit. The naming of System32 made sense back when they came up with it, but now it's a bit ridiculous. However, since there are so many incompetent Windows programs using hard-coded paths instead of SHGetFolderPath (including, BTW, literally every Java desktop app that doesn't include its own shim-- the JVM itself has this bug!), it's something Microsoft doesn't have the ability to fix.
  - maxlybbert 10y ago
    I doubt it would be hard, but I don't see why anyone would bother. At my last job, we would occasionally need to dig up old code because Microsoft finally removed something they had deprecated several years before. I think it was always amusing. One case that stands out was a utility program that would update data for our users each month. I needed to change something about the string handling. After updating the data, the program would enumerate all running software and kill any copies of our program (so that they would need to read the new data on startup). I noticed that we went through the trouble of enumerating 32-bit and 16-bit programs. Since we hadn't shipped a 16-bit version of our software since the '90s, and we had changed our data format significantly since then, I happily ripped that code out. I don't think you can find information on 16-bit Windows on MSDN anymore. I guess, to put it another way, who's shipping 16-bit programs?
  - 0x0 10y ago
    Pretty hard. It's not just a matter of executing 16bit assembly, you also need to handle mapping every single window message and callback between 16bit handles and the real native handles, of which there are thousands and the meaning/interpretation of parameters are unique for each one. This guy is doing just that in .NET. While he uses a full blown CPU emulator for executing 16bit x86, the hard part is all the thunking and bidirectional mapping of handles and memory pointers and stuff: https://medium.com/@CantabileApp/implementing-window-messaging-in-win3mu-979a0ea31571 https://medium.com/@CantabileApp/implementing-window-messagi...
    - derefr 10y ago
      This seems like the harder strategy of the two. What about simply having a small Windows 3.1 or 95 VM that gets run in the background under HyperV, with fresh VXDs written for it to allow it to use paravirtualized resources, so as to allow it to do the same sort of "infinite framebuffer canvas used to back native windows for the compositor" tricks VMWare's Unity mode and the like do?
      - 0x0 10y ago
        Doesn't MS already ship this as a "Virtual Windows XP Mode" based on VirtualPC? The huge downside is of course the lack of integration with your main OS - copy&paste and drag&drop of rich/dynamic content, OLE embedding, keyboard settings, shared file systems and drive letters, printer drivers, all sorts of windows preferences, applications installing random global windows hooks, etc etc.
- beached_whale 10y ago
  Pretty sure it was MS cutting the 16bit API and amd64 has 16bit real and protected modes Yup! https://en.wikipedia.org/wiki/X86-64 https://en.wikipedia.org/wiki/X86-64
  - Aloha 10y ago
    the VDM used for 16-bit Windows on WinNT required "Virtual 8086 Mode" which is not accessible while in long mode (64 bit)[1] Now Microsoft probably could have engineering a real solution to continue DOS/16-bit support - either via VT-x or just a different solution. But it would have cost engineering hours - for what is a diminishing return. [1] - https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_VMX_support https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_V...
- amluto 10y ago
  > Unfortunately no 16-bit Windows executables work on 64 bit, True. But the do work on Wine on modern 64-bit Linux. :) In fact, even DOSEMU works on modern 64-bit Linux -- take that, Windows backwards compatibility! (But use DOSEMU2 if you do this -- it's better supported.) > since x86-64 processors lack the ability to run in 16-bit mode. Not true. 64-bit processors running in "long mode" (i.e. running a 64-bit kernel) can't enter "virtual 8086" mode, which makes various real mode emulation (DOS non-protected mode, for example) awkward. But modern CPUs are so fast that they can emulate this kind of code very well, and CPUs with virtualization extensions can run real mode or virtual 8086 mode code in a VM even when the host is 64-bit. (64-bit kernels can, in theory, switch out of long mode temporarily, but this is an incredible mess. Linux used to do it for certain UEFI compatibility scenarios, but this proved to be deeply problematic, and Linux doesn't do that any more.)
  - andrewf 10y ago
    Could you talk a little more about DOSEMU2 versus DOSEMU? I'm literally spinning up DOSEMU today to run a bunch of old DOS compilers (Watcom). I can't find much on DOSEMU2 other than its release logs, which seem focused on games and amd64. I think that Lredir/emufs (access to the Linux filesystem) and "dumb" stdin/out are important features to me.
    - stuaxo 10y ago
      I think Stas Sergeev wanted a place to do bigger changes to dosemu at the same time as Bart Oldeman has been stepping back / busy with other things. So Stas made a dosemu2 repo on github, with the additional benefits of being a more modern development environment than sourceforge. It's worth having a play with, some of the older more knarly parts of the source are getting dealt with.
      - amluto 10y ago
        Stas also tells me when I accidentally break dosemu2, and dosemu gets updated to take advantage of newer kernel features. Headline features include espfix64 (for more accurate returns to DOS code from interrupts) and proper SS sigcontext support (ditto). Lifechanging, I know :)

by dsp1234 10y ago

umanwizard 10y ago

Unfortunately no 16-bit Windows executables work on 64 bit, since x86-64 processors lack the ability to run in 16-bit mode.

derefr 10y ago
I keep seeing this statement, and it's making me wonder: how hard would it have been for Windows 10 to simply ship with a 16-bit WinAPI-binary transpiler (ala Rosetta) or emulator (ala DOSBox)?
- raverbashing 10y ago
  There was something called WoW, not sure it did that But at this point I can see why MS would not bother with it
  - mishac 10y ago
    IIRC WoW just provided a layer to point 32bit binaries to 32bit libraries on 64bit systems. So you have the ass-backwards situation where %WINDIR%\System32 is full of 64bit dlls, and %WINDIR\SysWOW64 is full of 32bit dlls.
    - akira2501 10y ago
      In traditional Microsoft fashion, it's both [0]. WoW is the 16bit compatibility layer on 32bit systems, WoW64 is the 32bit compatibility layer on 64bit systems. [0]: https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
    - blakeyrat 10y ago
      The original WOW was doing a 16-bit to 32-bit layer. WOW64 (in 64-bit Windows OSes) does 32-bit to 64-bit. The naming of System32 made sense back when they came up with it, but now it's a bit ridiculous. However, since there are so many incompetent Windows programs using hard-coded paths instead of SHGetFolderPath (including, BTW, literally every Java desktop app that doesn't include its own shim-- the JVM itself has this bug!), it's something Microsoft doesn't have the ability to fix.
- maxlybbert 10y ago
  I doubt it would be hard, but I don't see why anyone would bother. At my last job, we would occasionally need to dig up old code because Microsoft finally removed something they had deprecated several years before. I think it was always amusing. One case that stands out was a utility program that would update data for our users each month. I needed to change something about the string handling. After updating the data, the program would enumerate all running software and kill any copies of our program (so that they would need to read the new data on startup). I noticed that we went through the trouble of enumerating 32-bit and 16-bit programs. Since we hadn't shipped a 16-bit version of our software since the '90s, and we had changed our data format significantly since then, I happily ripped that code out. I don't think you can find information on 16-bit Windows on MSDN anymore. I guess, to put it another way, who's shipping 16-bit programs?
- 0x0 10y ago
  Pretty hard. It's not just a matter of executing 16bit assembly, you also need to handle mapping every single window message and callback between 16bit handles and the real native handles, of which there are thousands and the meaning/interpretation of parameters are unique for each one. This guy is doing just that in .NET. While he uses a full blown CPU emulator for executing 16bit x86, the hard part is all the thunking and bidirectional mapping of handles and memory pointers and stuff: https://medium.com/@CantabileApp/implementing-window-messaging-in-win3mu-979a0ea31571 https://medium.com/@CantabileApp/implementing-window-messagi...
  - derefr 10y ago
    This seems like the harder strategy of the two. What about simply having a small Windows 3.1 or 95 VM that gets run in the background under HyperV, with fresh VXDs written for it to allow it to use paravirtualized resources, so as to allow it to do the same sort of "infinite framebuffer canvas used to back native windows for the compositor" tricks VMWare's Unity mode and the like do?
    - 0x0 10y ago
      Doesn't MS already ship this as a "Virtual Windows XP Mode" based on VirtualPC? The huge downside is of course the lack of integration with your main OS - copy&paste and drag&drop of rich/dynamic content, OLE embedding, keyboard settings, shared file systems and drive letters, printer drivers, all sorts of windows preferences, applications installing random global windows hooks, etc etc.
beached_whale 10y ago
Pretty sure it was MS cutting the 16bit API and amd64 has 16bit real and protected modes Yup! https://en.wikipedia.org/wiki/X86-64 https://en.wikipedia.org/wiki/X86-64
- Aloha 10y ago
  the VDM used for 16-bit Windows on WinNT required "Virtual 8086 Mode" which is not accessible while in long mode (64 bit)[1] Now Microsoft probably could have engineering a real solution to continue DOS/16-bit support - either via VT-x or just a different solution. But it would have cost engineering hours - for what is a diminishing return. [1] - https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_VMX_support https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_V...
amluto 10y ago
> Unfortunately no 16-bit Windows executables work on 64 bit, True. But the do work on Wine on modern 64-bit Linux. :) In fact, even DOSEMU works on modern 64-bit Linux -- take that, Windows backwards compatibility! (But use DOSEMU2 if you do this -- it's better supported.) > since x86-64 processors lack the ability to run in 16-bit mode. Not true. 64-bit processors running in "long mode" (i.e. running a 64-bit kernel) can't enter "virtual 8086" mode, which makes various real mode emulation (DOS non-protected mode, for example) awkward. But modern CPUs are so fast that they can emulate this kind of code very well, and CPUs with virtualization extensions can run real mode or virtual 8086 mode code in a VM even when the host is 64-bit. (64-bit kernels can, in theory, switch out of long mode temporarily, but this is an incredible mess. Linux used to do it for certain UEFI compatibility scenarios, but this proved to be deeply problematic, and Linux doesn't do that any more.)
- andrewf 10y ago
  Could you talk a little more about DOSEMU2 versus DOSEMU? I'm literally spinning up DOSEMU today to run a bunch of old DOS compilers (Watcom). I can't find much on DOSEMU2 other than its release logs, which seem focused on games and amd64. I think that Lredir/emufs (access to the Linux filesystem) and "dumb" stdin/out are important features to me.
  - stuaxo 10y ago
    I think Stas Sergeev wanted a place to do bigger changes to dosemu at the same time as Bart Oldeman has been stepping back / busy with other things. So Stas made a dosemu2 repo on github, with the additional benefits of being a more modern development environment than sourceforge. It's worth having a play with, some of the older more knarly parts of the source are getting dealt with.
    - amluto 10y ago
      Stas also tells me when I accidentally break dosemu2, and dosemu gets updated to take advantage of newer kernel features. Headline features include espfix64 (for more accurate returns to DOS code from interrupts) and proper SS sigcontext support (ditto). Lifechanging, I know :)