Microsoft released Word for DOS even after the Windows version came out, and I remember a lot of people were surprised that they bothered -- 5.5 was even transformed into a curses-style "graphical" DOS app  with colour, drop down menus (with shadows!) and mouse support (but drawn with ASCII characters), similar to Borland's DOS apps, but it seemed like a perfunctory release -- at that point it was obvious DOS was legacy and that Windows was the future of Microsoft.
Here's a screenshot from version 1.15: https://winworldpc.com/res/img/screenshots/1x-dos-e22144b8ec...
And to Visual Basic for DOS.
VB for DOS was a bit different, and tried harder to look like Windows (3.x). You can tell by looking at push buttons and window decorations:
It supports multiple overlapping windows, including modals, and since window rendering is based on buffers, it automatically supports things like region repaint and shadows; it comes with an extensible file editor that supports selection, clipboard and undo/redo; form validation; and even persistence (any UI widget, or set of widgets, can be written to disk and read back again).
It's quite an advanced object-oriented toolkit that's impressive even now, though it seems a bit insane today that they spent so much effort on something that could render only VGA's 80x25 characters.
Documentation is spotty, but it exists .
Oh, and it's available on all platforms, not just Windows!
So not only is this one of the earliest examples, but probably the largest example of correct Hungarian.
It could be interesting to list them here. If you know one ancient piece of code with Hungarian notation please tell!
Morristown, NJ 07960
The 'obscure language' used is troff: https://en.wikipedia.org/wiki/Troff
My father worked in Morristown at Telcordia Technologies/Bellcore in the 1980s/90s and before that at Bell Labs in the 70s.
Seems somehow related though, what with the troff commands.
Here's where the example is from, it appears:
So... not Bell Labs, I guess, but maybe something related?
Telcordia/Bellcore was a spinout from Bell Labs after the DOJ antitrust action in the early 1980s. Bell Labs stayed with AT&T and Bellcore was the R&D lab for the newly created Baby Bells composed of many staff from Bell Labs.
FUTURE: MacWord does a DoJump(&venvMainLoop) !! (which,according to DavidLu is "guaranteed to crash soon there after"). we should really figure out a better way...
Who is DavidLu and did this ever get fixed?
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)
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.
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.)
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.
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.
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.
 - https://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_V...
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-messagi...
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.
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?
But at this point I can see why MS would not bother with it
So you have the ass-backwards situation where %WINDIR%\System32 is full of 64bit dlls, and %WINDIR\SysWOW64 is full of 32bit dlls.
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.
Is there any way, we can run windows 1.1, and get this up and running as of today?
UPDATE: This is the thread from the time of the release: https://www.betaarchive.com/forum/viewtopic.php?t=31096
(see my question in the thread)
$ grep -i fuck * -r
Opus/asm/wordgrep.asm:; BP is used as always, the other registers are free to fuck with.
Opus/asm/wordgrep.asm: je another_fucking_out_of_range_jump
Ironic as MSR-SVC was shut down a few months after this article was written.
And they still would probably have lost that market to Word for the same reason the whole stack of players that did compete in that market did: no one in the mass market is regularly writing and laying out books, they are either mostly writing documents of a few pages with the occasional longer work, or preparing copy and art.that ia going to be fed into some publisher's layout system.
Many years later, and I'm still writing Windows programs. Excellent strategy on Microsoft's part.
Nice to see this hugely transformative software available in an archive.
"Yes. I give you my Word."
This still describes Word, 32 years later.
(I'm currently using a mouse which has been operating in close proximity to a keyboard for some years now, so I can attest that at least his latter complaint hasn't weathered the test of time.)
Compare this to, for example, in design, and you'll see why Word is hated by the print industry.
Of course it may not be practical for casual users to learn the object model.
While Word is still widely used today, I expect it to gradually fade away as people produce fewer documents for the printed page. Per-capital paper consumption in the USA has been slowly declining since 2008.
I have, and I think you highly overestimated how easy to use mercurial or these other tools are.
I had with various success, in the end it all comes down to how open minded those people are. I wish version control would be more prevalent in academia and research where it's really needed for transparency reasons, I wish more groups would also use csv, tsv ,JSON files + Python data wrangling tools instead of Excel.
My problem is more when the UI is changed without any benefits.
The one thing I really dislike in Office 2013/2016 is the animated cursor. In Word it's just a distraction, but in Excel it is ludicrous: when I click on a cell, I'm looking at that cell, I'm not thinking about the cell the cursor used to be on at all, but for some reason Excel wants to draw my attention back to the previous cell just so I can watch the cursor box move. This is not something to benefit the user, it's a designer screaming "Look at me!"
Fortunately, there is a way to turn off these Office animations and a lot of other animations too. Open the Ease of Access Center in the Windows control panel and select "Make the computer easier to see". There's an option there to "Turn off all unnecessary animations".
This stops the animated cursor and some other animations in Office, and it also turns off the goofy Start menu animation. To my eyes it is a nice improvement.
I just double-click a menu item to collapse the entire bar, which ends up using the same space as an old school File menu would. Then I tap `Alt` to bring up the shortcut letters and tap them to activate features. It's incredibly fast and essentially modal. Gives me a good Vimy feel.
Office 2013 and newer also has a full-screen mode which hides all the menus and lots of chrome, giving you mostly data. It's the only way to use Outlook and Excel with maximum screen efficiency.
This. The only reason I fire up any Office app these days is if something I'm doing has gone horribly wrong (as in, causing an Office app to be the best tool for the job) but if the ribbon was down the side of the screen instead of the top, I wouldn't be nearly so mad at it.
I could see how you could conclude that your complaining was for complaint's sake, but mine?
Our industry-standard reasoning is good when all you make is cheap shiny toys that need to get popular quick to attract investor money. Much less so if you want to design software that empowers its users to do more.
EDIT: Vim/LaTeX mention borrowed from parallel comment of 'beefield.
Let me give you an example of a complicated product where the user-interface can be made friendlier. I worked on a C/C++/Fortran compiler (PathScale) for a while. Users would compile non-standard-conforming programs, get the wrong answer, and then tell us that we had a bug in our compiler. I got the compiler guys to add some compilation flags for things like "use C argument aliasing rules in Fortran". Then when a user reported this class of bug, we had a section of the manual which said: "Compile with these flags. If you now see the correct answer, figure out which flag fixed your program, and then go read the appropriate paragraph in the manual explaining how your program is not standard-conforming." It worked great for both our in-house customer support people (who used it all the time) and customers (who might use it once or twice, usually after being prompted by our customer service people.)
I do appreciate Office maintaining support for all its legacy keyboard shortcuts in Word and Excel. Literally run Office in a Windows VM on my Mac for those shortcuts...
After I got out of school, I switched to BBEdit, and Pagemaker if I needed formatting. And now vim is my world. Libreoffice gets to annoy me if I need paginated formatting, but that happens less and less.
Now 95% of my tube time is in Emacs, and most things are written in LaTeX. Though occasionally I still need Word, and I've been happy with Office for Mac (2016?) so far. (I really want to like LibreOffice, but...)
This is pretty much same for everything. Could describe me trying to use a Mac after years on Windows.
(References to both found in http://antitrust.slated.org/www.iowaconsumercase.org/011607/...)
So basically if you bought Gateway PCs with Windows 95 you got Office 95 Pro for free with them. In a cost-constrained environment it was a no brainer compared to spending money on Wordperfect licenses.
When I got there it was mainly Wordperfect for DOS and Lotus 1,2,3 for spreadsheets but when we rolled out new PCs with Windows 95 we migrated to Excel and Word.
In terms of productivity there was a definite hit for "pro" users where they were faster with Wordperfect than Word but it was possible to get past that and Word used to have a pretty useful compatibility layer so you cold use Wordperfect commands in Word.
There are still grumpy graybeard lawyers today using WordPerfect v.whatever from 1996.
Later on they got squeezed between IBM muscling their customers onto Lotus Notes and Microsoft. That put them in the grave and Exchange filled it in.
Does this conflict with the terms of the Open Specification Promise? https://en.wikipedia.org/wiki/Microsoft_Open_Specification_P... If so, does that taint anyone working on a project involving DOC word documents?
I mainly use MS Word to open documents shared by Clients and to check the resumes of candidates which are generally in MS Word format in India.
Google Sheets also have improved a lot over the past year or so.