ReactOS is in Alpha
Which is where Windows 10 currently is.
Axel Rietschin, kernel engineer at Microsoft, has claimed that ReactOS, an open source operating system intended to be binary-compatible with Windows, is "a ripoff of the Windows Research Kernel that Microsoft licensed to universities." Rietschin, who is currently "Senior Software Engineer (Windows Base Kernel, Container …
Windows NT was more or less a straight copy of VAX/VMS, apart from some of the more obvious features such as the GUI - which Bill Gates insisted had to stay recognisably the same as in Windows 3.
That much was obvious to anyone who studied the internals of VMS and WNT - many of whose system calls had virtually identical names.
"Windows NT and VMS: The Rest of the Story"
It is clearly inspired by VMS. But then that's understandable -- the lead author of Windows NT was David N. Cutler, who had been the leader of VAX/VMS back in the late 1970s, and of RSX-11 before that. So he could re-implement the parts of VMS he liked most from memory. But a lot of good things in VMS are missing from Windows. Take, for instance, device names. Windows follows the MS-DOS tradition of A: and B: for floppies, C: for the system disk, etc. Kinda limiting. VMS uses longer names, like SYS$SYSTEM, and lets the administrator assign them to devices as they see fit. VMS also had four rings of protection (K E S U), implemented on VAX hardware.
Windows NT was more or less a straight copy of VAX/VMS
Windows NT 3.5 was a pretty-much straight ripoff of OS/2. Then MS redid things for NT4 by hiring the guy who did the VAX/VMS kernel and got him to write the NT kernel.
Unsurprisingly, they were remarkably similar (until the rest of MS got hold of it and what was originally a nice clean design got increasing byzantine and convoluted..)
Seems Axel Rietschin is both far too young to know that and has suffered brainwashing at the hands of the Microsoft marketing department or otherwise he wouldn't be so stupid to make such utterances.
P.S.: Also, it's pretty much proof he failed history at school.
This sounds like a re-run of the accusations SCO were making about Linux right at the beginning of their infamous onslaught against Linux. (Their lawsuit being funded by Microsoft, as was later discovered) Essentially, the accusation was that something of the quality and complexity of the Linux kernel could not possibly have been put together by a bunch of "unwashed hippies", so therefore it must have been stolen. A lot of people took this seriously at the time, before it was shown to be a bunch of lies. Is there any reason to suppose this latest accusation is any more plausible?
Well if you read the article yes.
They don't claim that the code copied is too tricky for dumb ReactOS devs to understand, they say that private macros and methods that were never part of public interfaces are the same in Windows and ReactOS. It's possible that they've coincidentally ended up with the same names for private functions, but unlikely.
But, tbh, 20 years of shoulder chips aren't gonna be dislodged by a little logic, are they?
"never part of public interfaces are the same in Windows and ReactOS"
How can we be sure that M$ hasnt copied the names used in ReactOS? Their source isnt public, its just their word.
If some source was viewed then that does not mean that it is a verbatim copy, just that maybe the names were reused. Also the guy says that many names are merely similar. What names? If they are named after a specific set of functons/functionality and use a similar naming convention as in the windows source then its not too hard to imagine that they may be similar.
Not really: There is no formal statement from Microsoft Corporate mentioned in the article or the posts, just an assertion from an individual - a former contractor to MS as of this year - though he does reference the opinions of more senior people that have worked on the kernel.
The post does mention that he thinks MS probably does not care given that "ReactOS aligns with a very old version of the NT kernel".
Right, wheel out an 'unknown' name like 'Axel Rietschin' to present its corporate thinking and Microsoft can deny or say whatever it likes later with impunity.
...And why target ReactOS after all this time? Perhaps ReactOS is actually getting close to being useful.
There's just one problem.
Just like with the SCO crap. And just like the crap that Microsoft claimed at about the same time.
No one has seen the code that they claim is stolen.
Well you can see it, under an NDA.
The problem is that if you see it, the NDA keeps you from even saying that you have seen it.
You just have to take their word for it.
And we all know that Microsoft would never lie about a thing like that.
So can someone tell me again, that Microsoft still isn't up to it's old E.,E., and E. tricks?
Inquiring minds want to know.
"No one has seen the code that they claim is stolen."
Yes they have, it said in the article the code was opened to universities. Also, Windows code can be seen by any EA customer that asks to see it so it's hardly secretive.
> Just like with the SCO crap.
There were two major obsticles that The SCO Group (TSG) had. The first was that Novel did not sell the copyrights of the code* to SCO or TSG, these were specifically excluded from the bill of sale. The second was that much code from BSD may have been legally included in both Unix and Linux so identical blocks of code did not necessarily make a case.
* In order to include the copyrights in the sale Novell would have to track down all the contributors and get their approval for transferring their copyright to SCO. As this had been done by thousands of companies and individuals it was an impossible task, so no copyright transfer. This did not mean that Novell retained the copyrights, there may not have been any that were protectable.
"Just as such features were identical in VAX/VMS and Windows NT."
Where they? One was written in assembler, the other in C.
The NT kernel was written from scratch by a team that was substantially the former engineering team that worked on the next version of VMS - they were not claiming to be reverse engineering the kernel in the same way that ReactOS is claiming to be working to provide a mirror product of Windows.
> The NT kernel was written from scratch by a team that was substantially the former engineering team that worked on the next version of VMS
And when DEC sued over the design of that new version being stolen MS settled for an alleged $100million plus various other items such as supporting Alpha processors and joint marketing of NT on Alpha.
> There is no indication that the threat made by Digital and the funding provided by Microsoft for work to be performed by Digital were linked.
There is no indication that DEC did any work for Microsoft for that money.
"""DEC also believed he brought Mica's code to Microsoft and sued. Microsoft eventually paid US$150 million and agreed to support DEC's Alpha CPU chip in NT. """
Depends how many and how much the same they are. It wouldn't be at all surprising if two macros that did the same thing ended up being called the same thing by two independent developers. In a huge code base that's going to happen a lot. Are there any statistics or is it just one bloke saying "it's a lot"?
> which is why Android require a patent license from Microsoft.
There have been specific items that are implemented by phones that may require a licence for a patent. One example is SD cards using VFAT where MS held a patent on some filenaming mechanism. If the phone does not have an SD slot or does not use VFAT then no licence is required. This is regardless of whether it uses Android or any other OS.
This why some phones do not have an SD slot, they avoid the MS licence fees.
... reformat the drives to another file-system ...
For you, me, and others of the technical calibre communing here, fine. For the other 99% of users, that would just result in a lot of support calls when the user can't read the card they inserted, or can't read it when they take it to another device. Asking users to install foreign file-system support on their PCs isn't going to work either.
There's a reason Micro$oft have held out for so long and refuse to support any other filesystem. Their business model is still built on restricting choice and enforcing lock-in. That model is starting to show cracks (like them having to give in and support Linux in Azure), but natively supporting other than their own FSs in Windows isn't something they've apparently seen too much pressure over. It's a self fulfilling loop - device vendors need to support VFAT for compatibility, that need isn't going to change while everyone supports VFAT - and M$ can sit back and watch the patent fees for implementing VFAT roll in.
For you, me, and others of the technical calibre communing here, fine. For the other 99% of users, that would just result in a lot of support calls when the user can't read the card they inserted, or can't read it when they take it to another device. Asking users to install foreign file-system support on their PCs isn't going to work either.
The *smart* thing (ah, there's my mistake right there) for the various device makers to have done would have been to make an industry-wide decision to support something like EXT4, FlashFS, whatever in their devices (cameras, media players, phones, tablets, etc) and merely provide a driver install for that particular filesystem. MSWindows does have an "installable file system" capability, it's been there probably as far back as MSWin NT 3.x. It wouldn't be any different than the bloated and overbuilt driver packages they want you to install now, and people manage to make that work no problem. And once it's installed for one device, you can read flash/SD/USB from anyone else that uses the spec.
But that would have required the consumer electronics industry to be something other than lazy, chickenshit cowards.
> when Windows was the more familiar system.
The original Microsoft PDAs and phones used a GUI that was like Windows itself. These had 40% of the US smartphone market at one point (prior to iPhone). Windows Phone 7 was entirely different from the contemporary Windows and from Windows Mobile 6.x. Consultants told MS that the low acceptance of WP7 was because the UI was UNfamiliar. The advice was to make Windows 8 use the WP7 UI so that it would
become familiar be forced down everyones' throats until they demanded it on their phones.
> These had 40% of the US smartphone market at one point
Only because the market was so tiny that they had almost no competition. Windows on a PDA form factor is HORRIBLE, absolutely ghastly and miserable all around. Just because it's familiar doesn't make it any good. The fact that iPhone (with a decent UI) instantly killed it is proof enough of that. The new Windows Phone OS was Microsoft trying to copy the iPhone/Android UI.
Your point is valid, but how often in reality do you remove the SD card from your phone?
(In my case, only if I'm totally wiping the phone and want to do likewise with the card so I can reinstall whichever OS from a clean slate)
It's just as simple (if not more so) to join the two together with a USB cable, and let the devices figure out between themselves how to transfer files - the only obvious difference I can think of might be the transfer speed achievable (though is that even an issue these days with the speed of current USB subsystems?).
>It's just as simple (if not more so) to join the two together with a USB cable, and let the devices figure out between themselves how to transfer files
Personally, as I don't possess a USB cable that could be used to link two phones together, I've found WiFi (with an appropriate app) to be the simplest way to link two phones together.
I'm all for this: Just get end-users to install FUSEFS drivers on their win-boxen in order to read the SD cards, which would include ext2/3/4 and other common file systems. I know MS would really HATE that, but the development effort (and WOW factor) would be TOTALLY worth it - saving money on VFAT licensing while they're at it.
it would also provide a universal FUSEFS implementation that everyone could use. Google could do this and it would make TOTAL sense. If done right, it would TOTALLY circumvent Micro-shaft's HORRENDOUS policy of FORCING ALL DRIVERS TO BE SIGNED BY _THEM_ for example.
He's over-egging it a bit.
As the discussion shows, a bunch of symbols doesn't really mean much when several hotfixes, public symbol servers, and even builds of Windows have included them by mistake. Reverse engineering those "affected" files in the normal way would easily reveal private symbols.
Macros and inlining is a lot more subjective. A reverse engineer wouldn't un-inline anything initially, if the original compiler had inlined them. But they may well easily spot a large number of repetitive code tracts and inline them themselves. Macros is similarly dubious ground, but it would be a court case to prove it.
ReactOS's problem isn't legal... or Microsoft would have been breathing down their necks long ago. It's that it's 10, 15, 20 years behind. If it did ever catch up, I'm sure Microsoft would sue it into oblivion whether or not they had a case, but they're just not a threat because it just doesn't do very much. Even Wine can be an absolute pain in the butt for the simplest of things.
I do see ReactOS as an unworthwhile venture. It's an awful lot of developer expertise, time and effort put into ultimately replicating something that such people (and UI designers, etc.) were rejecting as poor examples of an OS when it was "modern", let alone all these years later. Compatibility layers have proven themselves to be of short-term limited value over just recreating the whole thing properly (or we'd all be running Ubuntu on NTFS). Samba is similarly dragged down by its AD implementation... CIFS is a fine idea for compatibility, even LDAP-based login on a Windows AD, but the whole "Linux as a seamless AD for Windows clients" thing is really just "throw it out and start again".
Given the hassle, I think if we'd just started a DE that looked and operated like Windows (no reason it couldn't be just a DE) and then a file compatibility layer, and then something like Wine for actual executables, we'd be years ahead of where we are now and it might be a viable "Chinese device knockoff Windows" rather than what we have now (which is pretty much undeployed and useless). There's no reason that, on top of a Linux base, you couldn't reimplement something that looked like, worked like, was compatible with, and did everything Windows does in a Windows way, even down to filename case insensitivity, etc. but running on a modern OS.
Hell, that's where I'd start even if I was trying to make a Windows-layer... just do that, then as someone makes the Windows API known to you, start to utilise it and build compatibility shims, changing explorer replacements for actual explorer, etc. ReactOS is - as it stands - poor man's reimplementations of very basic Windows utils, sitting on a very basic desktop, trying to sit as an OS all by itself, with very little hardware support. They've aimed at the bottom, despite most people only ever caring about the top.
Even Wine can be an absolute pain in the butt for the simplest of things.
Can be, but is usually a pain for non-simple things, mainly games..
I've been running Daz Studio, on Wine for a couple of years, there's more than a couple of caveats, and issues, but minimal and getting less every release (and certainly less caveats and issues actually having Windows installed to run it would be).
I do agree with the concern about ReactOS, I also think it has very little chance of 'getting there' - the goal (the Windows platform) will almost certainly moved on (possibly off a cliff, a hole, or into a museum) by the time ReactOS gets reliably workably close. A lot of devs will have gain a lot of experience working on it, so nothing is a total waste.
As to a Windows-like DE on top of 'Linux - that's been tried a number of times (I still remember Lindows) - it'd never be seamless though, the Unix way of doing things will catch on windows addicts like a hangnail.
Certainly true for 32bit VB6 with serial OCX. Doesn't seem to work on any 64 bit version of windows, I tried Win7 & Win 10. Will run (don't know if I/O works) on the 32bit Win 10 supplied on "crippled" Atom tablets with 32bit EFI, even though 64 bit Atoms and it's possible to install 64bit Debian with 32bit EFI. You need to manually add the Debian 32bit EFI files to 64bit Mint before making USB stick, which isn't trivial.
You can easily install an ENTIRE Win 3.1 on DOSbox for 16 bits (nearly ANY OS / CPU). Which is how 32bit NT Windows up to XP ran 16 bit apps, NTVDM for DOS and WOW thunk 16->32 api for win3.x 16 bit apps. So 32bit and 64bit Alpha could run 16bit x86 code on NT4.0 32bit and 64bit, but no native x86 32bit windows applications. Shame HP/Compaq killed all the DEC products.
"ReactOS and WINE co-operate in development"
they DO but there are so many 'missing things' in BOTH ReactOS and Wine that I have to wonder where the effort is being focused at the moment... whether it's effective use of time, or "this is interesting to me right now" prioritization.
I had a short brush with how one group selects paid developers. I would say that their process, in and of itself, excludes the best and the brightest in exchange for ACADEMICS, because the people running the show _ARE_ academic, and (more than/? a bit arrogant about it. Apparently they've inherited some money, which means "they can have it THEIR way" whether it's effective or NOT. Their "standards" favor schoolbook responses to problems in lieu of seeing how well someone [with proper tools and experience] can crank out quality work at high speed and get things DONE.
So a big part of the ReactOS and Wine teams is their ACADEMIC ARROGANCE. If they want SUCCESS, they have to think like A BUSINESS, and *NOT* like a bunch of COLLEGE PROFESSORS, who couldn't manage their way out of a PAPER BAG given a MAP, and electric "opening" finder!
(though they might be able to find their ASSES with both hands and a map)
Evidence? It's more usual that someone in staging puts in a quick hack that enables a game to work in a particular configuration without consideration to what other applications it might break, or whether their code works with unusual hardware (i.e. real Windows might work with a 15/16 bit colour depth, and WINE borks)
"Reverse engineering those "affected" files in the normal way would easily reveal private symbols".
Please explain how you would get macro names out of this process. I assume the code is in C, in which case the copiler doesn't even see the macro names, as per 184.108.40.206, 6.2.1, etc.
@ReactOS: Anyone who has the extraordinary lack of imagination which would be required to reverse-engineer and copy a Microsoft kernel deserves everything they get, and more.
Programmers tend to use logical names for routines, variables, and macros.
A macro doing something would logically be named after what it does, even if that name then never makes it past the compiler.
So, a macro that reads a printer's status would be named along the lines of "read_printer_status" and used in several printer-related routines.
Such logically-chosen names make life easier for teams of programmers, especially when they're not all at the same location.
just think of the things ReactOS is "lagging behind" Micro-shaft with...
a) 2D FLATTY FLATSO McFLATFACE - not in ReactOS
b) "The Slurp" - not in ReactOS (nor are the ADS that Slurp selectively FEEDS us)
c) "The Metro" tiles and "Start Thing" and "Properties" pages - not in ReactOS
d) "The Store" - also NOT in ReactOS
e) The Arrogance - how MS treats customers these days - not in ReactOS
pretty much *EVERYTHING* *I* *HATE* that Micro-shaft EXCRETED post-7 is NOT IN ReactOS.
And that's a *GOOD* thing!
It’s to let cash-strapped people run software that won’t run well or at all under WINE/Proton and use devices that are not natively supported in Linux.
Yes, One can use Wine, PlayOnLinux, Lutris, etc. to run Epic Games launcher, but the overhead makes games perform worse than running under Windows 10. Also, Blizzard is an a*****e that tempbans users who try to play their games in WINE/Proton.
Not just bought the rights to sell it, but bought it in its entirety, including all source code and related intellectual property. Then using it as a starting point extended it and rewrote almost all of it so that it would pass IBM acceptance standards.
I realize that they have done a lot of questionable and blatantly unethical things since, but there wasn't anything wrong with what they did then.
I would say buying someone else's work and representing it as your own instead of as a derivative work, does not meet criteria for we're honest representation of origin.
It's wrong because it purposely represents its origins and development inaccurately for marketing purposes.
It's wrong because it does not display all the information about it to the consumers.
Consumers cannot make responsible decisions s the methodologies and philosophies and type of person they are promoting into financial and social power through their purchases, if critical information is kept from them.
but the reason why you're hiding information is you're afraid other people will make better decisions then you're operating unethically.
"I would say buying someone else's work and representing it as your own instead of as a derivative work, does not meet criteria for we're honest representation of origin."
Then I suggest as a protest you throw any technology you have bought in the last 10, if not 20 years, as nearly every big player has bought in someone else's work and sold it as there own
Hell, Rubens flogged others artwork as his own and don't even mention Andy Worhol
Just because it's commonly accepted does not change the deceptive nature of the act.
It is deceptive by measure of function.
If you're going to operate by deception, I suppose it might throw a kink in your plans, if your deception is discovered.
So your argument is everyone's doing it? And that retroactively changes its objective functions it operates by?
That sounds insane.
If you buy something with terms that say you now own that thing and the original owner agrees, then you own the thing. After that, it's your thing to use as you see fit unless you choose to sell or give it to someone else. For example, Apple wanted a new OS in the late 1990s, so they looked around to find someone who had an OS, which they found. They then bought that one and used it to make OS X. Before Apple bought it, it was the work and property of NeXT and it was nothing to do with Apple. After Apple bought it, it was the work of NeXT and the property of Apple, and after pretty much the same engineers who worked on it at NeXT did some work on it for Apple, it was the work of Apple. If I write some code and then you join my team and we both work on it, the final product is the result of both of our endeavors and we both get the credit. If you pay me to join my team, I still get credit if I did stuff. If you pay me for the rights to the software I had a lot of credit for with the clear idea that you get the IP and rights to sell, then you can decide how it will be sold, including what the price will be, how you'll advertise it, and what name you use.
I would say buying someone else's work and representing it as your own instead of as a derivative work, does not meet criteria for we're honest representation of origin.
They represented the product as their own, and it was. They bought it, so they owned it ("their own").
At the moment MS bought QDOS, it was a Microsoft product, full stop. There's no inherent claim by MS that MS-DOS was originated within the company... the only claim is that they owned it, which was accurate.
Are you able to step outside of social and definitions to observe and measure what something is by interaction origin and history, components, and how it relates with the rest of the world.
What we called things or is not the same as what something is.
Law and social definition has the same relationship with reality.
> rewrote almost all of it so that it would pass IBM acceptance standards.
Actually IBM did some of the rewrites when Gary Kildall showed IBM that PC-DOS 1.0 could display a DRI copyright.
> but there wasn't anything wrong with what they did then.
Granted it was SCP that took CP/M 1.3 and 'decompiled' it to build QDOS. SCP needed an operating system to develop their 8086 based Zebra systems, the 8085 ones used CP/M and CP/M-86 was running late. 'Decompilers' were available which produced an annotated assembler listing* for a variety of commercial programs including CP/M BDOS (the annotations were hand written and attached to the assembler created from a genuine copy of the binary code). Intel had a converter that changed 8085 ASM into 8086 ASM. Compile this up and it was a "Quick and Dirty OS (QDOS)".
The original QDOS used CP/M file system so that an 8085 Zebra could be used to build a system disk then swap the CPU board (S100 based) to the 8086 and reboot.
So, was MS wrong to use a pirated system ? Both SCP and MS were full DRI OEMs and had everything that DRI provided to OEMs (MS for the Z80 softcard) so they should have known.
* The CP/M BDOS had actually been written in PL/M.
> In what Universe did a main frame computer company that was a market leader base a large scale product with an OS evolved from "Quick and Dirty Operating System"?
This one, though they didn't know that. They thought they were getting a 'version' of CP/M.
The IBM PC (5150) was intended to compete against Apple II with Z80 Softcard running CP/M and to be slightly better: more RAM (up to 256Kb for model A), larger disks (160Kb vs 120Kb), same software: BASIC, Visicalc, dBase II, ... and also act as a terminal*.
* The IBM PC serial ports are DTE (Data Terminal Equipment) while most micro computers were DCE (Data Comms Equipment). This indicates that the IBM PC would act as a terminal to larger machines. Also there was a 3270 emulation available.
Not this one. Your error is in the phrase "a large scale product". IBM thought the PC was a dirty little thing to get customers hooked on computers, at which point they would open their wallets to buy a proper one. (And then the PC ate their entire business for lunch, but hey ... why would anyone in the computer industry have ever heard of Moore's Law?)
> IBM thought the PC was a dirty little thing to get customers hooked on computers,
No. At the time users in IBM mainframe sites were buying Apple IIs with Z80 Softcards to run BASIC, Visicalc and Wordstar (and others). The PC was merely to keep the sites pure IBM and stop other brands infiltrating. This is why it was just a small improvement* on Apple II but also had versions that were 3270 terminals, 360 emulators (with two added boards running 68000s) and was only intended to be sold to IBM sites, not the general public. The PC itself was 'quick and dirty' being based initially on the System 23 (a word processor) planar and using already obsolete parts, such as the serial ports. IBM originally planned to build only 50,000 of them in total because that was the potential market within IBM sites.
* There were internal fights with the Series 1 division who felt threatened by a competing product inside IBM.
>B, gather evidence
There does seem to be an absence of evidence.
Given, from his claims, the guy had and may still have access to the Windows code released to Universities, I would expect much more specific examples that others could check and verify.
I therefore think this is more to do with sour grapes and trying to get their 15 minutes than any real substance.
It's not even an official MS statement?
They are not tardy about suing, even claiming complete ownership of things they derived from others. MS themselves was built on the dubious use of buying a reverse engineered CP/M 86 relabelled MS DOS and porting Dartmouth BASIC.
So without a court case, and MS wining it, it's the opinion of one MS employee even if it's true.
There is a problem with any alternate Windows. It needs to run all legacy code from Win3.1 16bit and Win NT3.1 32bit to 64bit Win 7, and very soon or there is no point to it, better to then use Linux and an XP or Win7 VM for legacy apps, or Win10 if you mysteriously can't migrate. Hence stupidity of some Linux Distro dropping 32bit Wine or making it tricky to install. For most users (not gamers), the whole point of WINE is the old 32bit programs that have never been updated and don't run on Win10 64 bit anyway.
the whole point of WINE is the old 32bit programs that have never been updated and don't run on Win10 64 bit anyway.
So you think Windows 10 is not worth avoiding if you can manage it?
That's probably the best positive testimonial Microsoft is going to get all year.
I don't think the 'Linux market for ancient 32bit apps is that huge, any company that trapped in the 32bit era is probably still running XP anyway (big shout out to the NHS and Greggs CNC mill).
We use systemd quite a bit for embedded stuff which is tailored per customer installation - mainly to provide a consistent way to manage process startup and watchdogging whether running full fat Debian or just Buildroot on some tiny ARM. The syntax is a bit arcane and debugging can be a bit of a bear, but there's not really anything better for free.
systemd is why I use Devuan and become *ANGRY* whenever I have to deal wtih its BRAIN DAMAGED nonsense, such as in Raspbian (on an RPi, to be used to control DEVICES, NOT a GUI), where it NEVER BELONGED IN THE FIRST PLACE, and my serial device connected via USB is WHAT THE FORNICATE being SCREWED UP ON BOOT by ModemManager causing 20 seconds of ERRORS during the boot process? WHAT the FEEL??? That was a non-obvious non-trivial BORK-UP by systemd!! Poettering deserves my eternal HATE. And it took WAY too long to TRACK THAT DOWN, too...
> And if you need 16-bit programs, that's where DOSBOX can come in.
It runs MS-DOS programs, but for running 16-bit Windows programs, DOSBOX alone is not sufficient. (I have used DOSBOX a lot, but so far never tried it for Windows code). You would first have to first get a genuine 16-bit Windows version running inside it. Googling, found the necessary steps here: https://www.howtogeek.com/230359/how-to-install-windows-3.1-in-dosbox-set-up-drivers-and-play-16-bit-games/
Honestly, given the adoption rate, maturity and obscurity quotient of ReactOS, methink going after it’d be a very poor use of legal $$$ at MS. (HURD being the other “who cares” OS poster child - no IP concerns there).
I’d be more excited about Haiku/BeOS, because that’s at least really different. Seems dead-ish too though.
No idea whether it’s true or not. He said, she said, pretty much.
> buying a reverse engineered CP/M 86 relabelled MS DOS and porting Dartmouth BASIC.
Actually it was a reverse engineered CP/M 1.3. Apparently PC-DOS 1.x still had a bug in FCB handling on a file close that was fixed in later CP/Ms.
> and porting Dartmouth BASIC.
It is much more likely that Altair BASIC was derived from a DEC BASIC interpreter used at Harvard for which source code was available. All development for Altair (and for MS-DOS) was done on DEC machines with cross compilers. While Bill promised to release source code for Altair BASIC this was never done (just like Trump's taxes).
You are right, Microsoft did not invent anything and their BASIC was a direct copy of DEC BASIC. Just like Microsoft's unathorised copy of CPM and NT (which was also taken from DEC), none of it was new or original. At the time all of Microsoft's stuff was copied from other people's work, so to hear them or anyone else complaining that others are taking their ideas and/or code is as shallow as the Hollywood movie companies complaining about infringement when they are only based in Hollywood in the first place so they could circumvent the legal rights of others.
Can they still sue? If ReactOS never signed an NDA, but someone else leaked the code... um "list of names"... (lol)... then can they still sue?
Some years back there had been some MSWin source code leaked to the internet. There had been questions/accusations that some of that code had made it's way into ReactOS, so the ROS project halted development for a time to do a full code audit, which turned out clean. They have been very clear about documenting the provenance of code.
Given that the full Win32 source code, minus the network stack, has been out in the wild since at least 2004, and without any copyright notice headers in any of the source files either, people are free to use them as they see fit. And it doesn't look like the MS copyright header notices were stripped either. There are a bunch of third party company header / source files in the 350MB odd of files that are part of the build stack and in those files the standard company copyright notices are still in there. Like from Adobe.
That\s US I.P law 101. You want to pursue an infringement, you gotta at least stick in the copyright notice and preferably register it too.
"without any copyright notice headers in any of the source files either, people are free to use them as they see fit."
They aren't, copyright is automatic in countries that signed up to the Berne Convention.
"You want to pursue an infringement, you gotta at least stick in the copyright notice and preferably register it too."
It helps, but isn't required, see here : https://en.wikipedia.org/wiki/Copyright_law_of_the_United_States#Registration_procedure
Registration and copyright notices only serve to make your case against violators easier, you are still in breech if someone can assert their copyright over the material in question, and a lack of just appears to mean you're less likely to get lots of money for your win.
You wont get very far with a copyright infringement, or even asserting a copyright i.p ownership right, in a court of law without any explicit assertion of that actual copyright. You know the "Copyright" or ©, "Owner", and "Year"...
Informal copyright is one thing, a legally binding ENFORCEABLE copyright for proprietary i.p is quiet a different matter. Those MS Win32 files had no notices anywhere. You know, the ones that legal had been telling us for years to stick in all source files that had any proprietary IP in them. I know because I looked long and hard for any of those notices in the Win32 source tree. Because I could not believe that level of negligence. Which it was. Even by MS standard it was pretty breathtaking. Those files that escaped were distributed to third party commercial partners. Its not like it was a purely internal build tree.
Just the opinion of someone who has been reverse engineering very proprietary i.p since 1984 and was first told to stick in the legally enforceable i.p copyright source code headers by the lawyers in ©1983. And has been directly involved in at least two high tech i.p cases that have their own wiki articles / sections. Which taught me that a tech person who knows the law will always beat a lawyer who knows the tech in those kind of cases. Because it turns out tech people are far better at thinking laterally about problems than lawyers. That's our day job. Thinking around problems. And in i.p cases a bit of lateral thinking usually makes the legal problems go away. The only problem you are left with then are idiot judges who dont know the law. Even the basic stuff. Pretty common on the Federal benches. In my experience.
Just the opinion of someone who has been reverse engineering very proprietary i.p since 1984 and was first told to stick in the legally enforceable i.p copyright source code headers by the lawyers in ©1983. And has been directly involved in at least two high tech i.p cases that have their own wiki articles / sections
"a legally binding ENFORCEABLE copyright [...] Those MS Win32 files had no notices anywhere."
That copyright notice, and the gibberish that goes around it, is usually to say that you CAN copy, and under what context (whether that be copy for installation like most commercial software, or copy fairly freely in entirety like GPL).
The creator can do whatever the hell they like. You, you get to follow the rules they choose and apply in the copyright (clue in the name - the right to copy), and if there is NO copyright attribution, that doesn't mean it's a "public domain" free for all, it actually means that you don't have any rights at all unless you can specifically prove that the owner granted you said rights.
"You want to pursue an infringement, you gotta at least stick in the copyright notice"
In that case, surely if you wanted to copy it you'd just remove the copyright warning and go right ahead? "Sorry m'lud, I didn't see any notice".
In much the same way as people pirating films generally remove the FBI "Copying is EVIL!!!11!" notice from the start.
I think you want to sit that US I.P law 101 class again.
You haven't needed to assert a copyright explicitly since 1989 at least. (However, the US is a little odd in that: Copyright under the Berne Convention must be automatic; it is prohibited to require formal registration. However, when the United States joined the Convention on 1 March 1989, it continued to make statutory damages and attorney's fees only available for registered works.)
P.S. The reason why is obvious - just because someone puts out a document, and someone else just literally removes the copyright line, doesn't give YOU (the casual user) a right to do what you want. At best you'd have to verify that they did that themselves. Else I just take your software, remove the copyright line, and distribute it all over the Internet. One naughty person, slap on wrist, billions of people get a free copy of Windows because it didn't have any copyright line on the copy *they* saw...
Work for Microsoft, "accidentally" push out a copy of all the source code but without copyrights from a Microsoft server, and everyone in the world gets to use that code in perpetuity? People at their competitors would pay you millions to do that for them, just once. The tech market would collapse overnight.
Please stop spouting such nonsense. It wasn't even true when the vast majority of Microsoft's customers weren't even born yet.
The tech market would collapse overnight.
No, it wouldn't. In fact, one might argue that the tech market might actually flourish, with the Weapon of Mass Monopolization once and severally neutered. Borland might actually still be a thing.
Please stop spouting such nonsense
Perhaps you should take a bit of your own advice?
Original: "The tech market would collapse overnight."
Response: "No, it wouldn't. In fact, one might argue that the tech market might actually flourish, with the Weapon of Mass Monopolization once and severally neutered. Borland might actually still be a thing."
Really? Borland would still be a thing? When people could find the source for its compiler and use it as they saw fit without paying Borland? How exactly would that have protected them? Sure, the Borland compiler might have been used more, which gives us some ground for a very detailed what-if scenario, but Borland would not have gotten any more money out of that. Also, you think the tech market would thrive when no company could turn a profit from selling their code, only doing support? I can tell you that investors wouldn't be so eager, which is how a lot of risky tech ideas get the ability to start. Sure, I'd love it if every company decided to give me their source for free and we'd see a lot of interesting open source activity surrounding that release, but that's because I don't really care about whether companies live or die; I'm not under the misapprehension that they'd do fine by handing over all their work.
> I think you want to sit that US I.P law 101 class again.
Nope. I sounds like you had not actually spent time, quiet a bit of time, over the last few decades on actual real world i.p lawsuits and how the are actually adjudicated. Writing expert witness statements, statements of fact, supporting evidence etc. That sort of stuff. In US courts. Both Federal and the State of California. You know, opinions based on experience in the real world. Not on some wiki article or some Nolo Press level books.
Have the slightest idea of what the actual Case Law is? International Conventions and Treaties and the Statute Law which enact those agreements is just the starting point. For Common Law courts, like Federal and 49 States, your case will be won or lost on the case law in most serious i.p cases. And who has the deepest pockets. The deep pockets is actually the more important bit. Unless you have all the case law lined up, and the counter case law against the others sides likely defense points, and or course, very deep pockets, you lose.
Thats how the law works in California. Do you have the slightest idea how it works in your jurisdiction? I'm talking real cases. With 7/8 figure settlements.
As for the twits who go on about stripping out the legal header in files. You just present in evidence the originals with the headers during the pretrial discovery and unless the other side has a suicidal streak, given that this opens up a whole bunch of interesting felony fraud issues, its no longer a civil issue, there will usually be a quick settlement agreement before the party infringed asks for a summary judgement which they would most likely get in their favor. Which opens up the possibility of really eye watering damages and penalties.
At least thats how I've seen these case play out in California courts over the years. Anyone out there have a different experience in i.p lawsuits brought to trial? It a very different game in Civil Law jurisdictions. But the basic rule still applies. Deepest pockets usually wins.
1 - you are confusing copyright with patent and trademark law. They are completely different.
2 - Microsoft has chosen not to publish the source code at all, which is their legal right. The fact that the copyright infringer chose not to place copyright notices on the infringing publication is not MS's fault.
They would still have to prove it is copyrightable. Sadly though, math and lists do end up slipping through the courts, even though technically they should not be copyrightable.
(IMO APIs should not be. It's like patenting trigonometry or algebra... we should allow protection of an individual work, or media creation, but if someone else makes a parody/simile/compatibility/equivalency of their own, then why shut them down?)
With Windows becoming slowly less relevant, now is the perfect time to open source it. Fundamentally, it's a good OS. Sure, it's got issues - but then what doesn't?
They could then follow the Red Hat model of paid support, all the while keeping Windows relevant.
Because about two days later someone would bring out Windows 10-2: Just like Windows ten, except all the telemetry is gone, it doesn't auto-install onedrive, doesn't nag you to set up a Microsoft account every time you install it, and has a start menu that actually opens first time, every time without trying to load up half the internet in smart tiles and an unwanted search of the Microsoft store.
And so what if they did? Chromium, which is by far most of the code in Chrome, is open source, and it continues to serve Google's corporate interests just the same. It's still Google who decides which bits of code get checked in and which ones get rejected, and the ones that don't serve Google's interests are clearly going in the "rejected" pile.
I wonder if that observation has anything to do with Microsoft's recent change of heart that has them "loving" Linux instead of thinking it's cancer.
MS clearly believed, during the Ballmer era, that even the possibility of the GPL coming in contact with their precious proprietary code, requiring them to (gasp) open-source some bits of it, would destroy them and their business model. You don't call a mere annoyance a cancer... something that spreads and causes annoyance would be likened to the common cold, perhaps. The comparison to cancer suggests something that would be deadly or fatal.
And then came Google with its (mostly) open-source Chrome, and they still maintain as much control over the Chromium base of Google as MS ever did with IE. Sure, there are lots of Chromium-based de-googled alternatives, but what do the vast majority of people use? The actual, spyware-filled Google Chrome. Google gets all of the control, but if they ever get investigated the way Microsoft was for anti-competitive behavior, they get the "it's open source" defense. They'll ask the governments, "How can it be anti-competitive when we gave the source code away, along with the blessing for anyone to use that code to create their own product?"
If Microsoft open-sourced Windows, and continued to develop it to serve their own corporate interests, there would surely be some de-Microsofted Windows versions out there, but as with Chrome, it's pretty safe to assume that by far, most people would still use the full Microsoft version. All MS would have to do is add some extras that are only available in the real thing (like Google does with Chrome), market the real version as being better (the "real deal" vs. the copies), and the OEMs would continue to distribute the "real" Windows rather than the derivatives.
Most people just use the OS their computer came with, so if MS was able to secure agreements with the OEMs to distribute the real Windows, which seems very likely, those people would still use Windows and not a derivative. Why would they use anything else? The ascendance of Chrome in the browser market and of Android in the mobile market strongly suggests that most people really don't care about privacy.
As with Chrome vs. de-Googled Chromium, the alternative, de-Microsofted Windows versions won't amount to much of the user base. It would have the added benefit of keeping the people who hate the spying and forced updates within the Windows ecosystem... they'd be using the de-Microsofted Windows, so the spying and forced beta testing would be out, but that would prevent those people from moving to Linux or Mac, and that strengthens Microsoft's position rather than the opposite.
All those people using de-Googled Chromium derivatives still show up as "Chrome" in the market share surveys (thanks to web sites that deny access to browsers with user agents they do not "support"), so they're still contributing to Chrome's perceived (and real) dominance that leads web and addon devs to favor Chrome. Some of them may think they're giving a big F-U to Google by not allowing the spying but still using Chrome, but they're not. They're still casting their vote for Chrome each time they visit a site that logs their user agent.
Similarly, the people using de-Microsofted Windows would still be supporting the Windows software market, convincing software devs that there is no need to support any other market. As it stands, the users that MS annoys enough to leave the platform go elsewhere and become an incentive for devs to write software for other platforms. If those disgruntled users went to an alternative, de-Microsofted Windows, they would still be incentivizing devs to stick with Windows.
That can already been done with NTLite. Admittedly you have to build it new with each major update if I'm right - or a WU will refresh the machine with a full 10 image. Removing integrated apps and telemetry components is robust though if you go deeper you can end up running into problems.
Windows is surprisingly modular although MS have made it very difficult to pick and choose. Just recently they changed DISM so removed components are just "hidden". In a day and age where most people are constantly connected to the internet you'd think could save bandwidth and SSD space by just having components download on-demand. Instead it's typically a 4GB+ iso unpacking to 20GB or more. The barebones for fully functional Windows 10 is less than half that.
This is classic old-style MS FUD. It seems the ghost of Ballmer is not yet laid to rest. But why now? What have ReactOS done recently to upset them? Gained market share, got something useful working, or just got caught in the crossfire of some other gameplay?
There was my thought. Only reason I could see for MS making a fuss is if ReactOS is potentially threatening them.
Or maybe MS is taking my suggestion of adding a Wine-like layer to MSWin10 and using it as a way to remove legacy APIs from the mainline WinXX kernel. Maybe ROS is in the way of that ?
Could we argue it is common knowledge now? 20+ years of students having access to the MS data tree/list, means yes... *names become common knowledge*.
What, you are going to say it's "coincidence" everyone uses my "Hello World" example I put under NDA 50 years ago? Where's my cheques!!!
The engineer didn't say "the same": he said "the same or similar names."
All it takes to end up with similar names for programming structures is similar naming conventions and similar goals. We already know that the goal is PRECISELY the same: processing binaries of a specific format to a specific result. And while there is some variety in naming conventions, there is also a lot of standardization, specifically within individual languages. In fact, I'd bet someone at least as clever as the two of us could come up with a test which does a fair job identifying a programmer's most frequently used or favorite language just by having them name some identifiers.
@AC - So is just by astronomical coincidence that it uses the same macros and names?
Care to list some, and give the version/edition of ReactOS and MS source code they coincide, so El reg readers can go compare?
Also can you evidence that MS was the first user of those macros, names etc. - just that it is surprising how much code was derived from textbooks (eg. Knuth, Dijkstra etc.) in the pre-Internet era...
Back in the '70s I wrote (and published in Dr Dobb's Journal) a patch to CPM 1.4 that added a /W extension to DIR. This has been active on every version of CPM and its successors since including MSDOS, Windows and REACTOS. If only I had copywrited that patch. I would have made a lot of money.
And that's fine for them. Kudos, even, for the work.
But a run at an open-source Windows-clone OS is rather a lost cause from the beginning: there is no way a small team of unpaid developers can keep up with Microsoft's OS. They can recreate Windows 97, I guess, some 20 years after the fact, but they can never catch up to modern Windows. And how many applications which are actually used in the year 2019 really run well on Windows 97?
Not knocking the ReactOS team. Their efforts are (arguably) more useful than making a touchscreen version of Atari. If ReactOS is their karma, they should follow it.
Now, what about security? The popularity of Windows makes it a malware magnet, a big fat bullseye for hacking. If ReactOS is Win32 compatible all the way down, then it faces the same panoply of attacks as old Windows computers would. Hmmm.
But I wish you all buena suerte, amigos. Have fun, and don't bother listening to squeaking from Rietschin -- it is full of sound and fury, signifying nothing. Nobody cares.
If the allegations are proven to be true (it will be up the courts to decide if Microsoft determines that the potential impact on its business merits lawsuits) then it has been a reckless decision that may well back-fire on the rest of the open source industry should law makers determine legislation is necessary - as has been the case with Articles 11 and 13 in the EU.
Nobody is suing nobody. Microsoft released Research Kernel (redacted Server 2003 kernel) to academia in 2004-2005 as part of Windows-based OS course curriculum. The universities signing up for this OS course agreed not to publish the code on outside and to use it solely for teaching and experimenting purposes. Nonetheless the code almost immediately appeared within public reach.
Did Microsoft sue the universities for breach of contract? No.
Was Microsoft so stupid not to anticipate it would happen? No.
I haven't seen ReactOS code, but I have seen Research Kernel code. Believe me, it is easily recognizable, so Rietschin is most probably right.
I dont know. Youd have to speak to someone whos been an MS kernel developer fir a long time - theres not many, most gave been poached a long time ago.
The MS bid needs to define 'public domain'. The early MSDN used to publish enough header files for dome to reverse engineer a lot. I remember going thru them in my DDK days and thinking 'Should this be in published headers?' MS are were sloppy on many different levels.
I hope reactos are not doing a vertabim winfows.
What would be killer would be a small NT 2k compatible kernel on L4 with the BSD network stack and ksh.
They had a contractor in in the early 90s.
Ripped of BSD, then MSified the interface, hence WInSock 1, 2 ,3, 4 ,5 ,6 ....
No, this would be take the BSD layer as is - -hey take th file system later, get ZFS ditch the crap MS whatever FS.
There is a *huge* latent demand to have WIN32 compatibility but not have the rest of the never ending breaking junk updates.
W2K (NT) on L4 - KSH, ZFS, BSD TCP/IP, DTRACE.
There you go, Ive just sorted out MS OS problems.
Stop whining over Windows 10 and Windows Server! ANYONE who has done long-term, low-level on and with ALL of the following Linux, Windows, VAX VMS, AIX, MacOS, Theos, AmigaOS, Atari GEM, MS-DOS, CP/M, iOS, Solaris, BeOS, QNX, and even OS/360, etc etc (aka ME!!!) knows that Linux and MacOS are basically crap and that Active Directory is pretty damn good compared to everything else. Only VAX VMS comes even close to Active Directory!
To put it mildly, Windows Server OSes and Active Directory are the Bees Knees of End-user and Group management systems and being able to right-click to choose properties and perform multiple actions REALLY IS a cut-above Linux, iOS, MacOS and Android! AND that File/Folder management (i.e. File Explorer) is FAAAAAAAR superior to what Linux and MacOS have!
Call me when all OTHER OSes FINALLY get a decent file, folder and data indexing, search and sorting/organization system!
"...AND that File/Folder management (i.e. File Explorer) is FAAAAAAAR superior to what Linux and MacOS have!"
Wow :-O have you ever used Dolphin or Konqueror for example? They are several years ahead of Windows File Explorer (even Konqueror that's very old), and this is just a small example.
Wine is not a emulator but it can run Windows programs and is real open source. Part of Wine code is used for ReactOS, but not all of it.
While at first Wine emulation was terrible (it crashed running notepad.exe!) it has greatly improved over the years.
Most Linux users know about Wine thanks to PlayOnLinux that makes easier to run Wine, mostly to play Windows games and old programs. Want to run Microsoft Office and is the 2010 version or older? PlayOnLinux is your pal! And yes, you can run 3D Pinball Space Cadet on Wine.
And even Steam is using their own version of Wine to run Windows games on Linux.
ReactOS meanwhile, will only be relevant the day Windows dies.
The day ReactOS becomes relevant is the day Microsoft sues them out of existence. It wouldn't even need to be a strong case - MS could drag in out for years, sue in multiple countries, and generally cause tens of millions of dollars in legal costs. The only reason MS allow ReactOS to exist is that it's too small to justify the bad press that could come of destroying it.
Several issues with this - clean hands, which has already been dealt with (Microsoft has not got clean hands); SCO versus Linux and the World, which likewise has been dealt with; and the fact that Microsoft has played around with releasing source trees of its OSes under various research and OEM licenses for quite some time - NT 4.0 back in 1996 or thenabouts, WINCE and the like under various licenses (now would be an excellent time for Microsoft to donate its early WINCE source trees under a BSD license to posterity), and various Embedded NT and derived source trees to OEMs. The infamous WinNT 4.0 and 5.0 source trees leaks were from a company in Israel, IIRC.
And then there's a book titled Windows for NT/2000: Native API Reference, and any number of other books dealing with disassembling WinNT kernels for delousing - oops, I meant debugging - app code system calls.
And the undeniable fact that Microsoft's attitude to ReactOS - the actual attitude as opposed to Axel Rietschin's whining - is such that they poached ReactOS developer Alex Ionescu, IIRC, because what he'd learnt reimplementing the Windows NT kernel and also writing Tinykrnl made him extremely valuable to them.
What people say can be interesting, funny absurd or anything else you like. But what they do when they put their cold hard cash behind it, tells what they really think.
ReactOS should focus on the part of Windows that handles drivers, so that hardware with 32 bit drivers only can be used with 64bit hardware and Linux - IF drivers would not be available there for such hardware, without the need to buy an additional Windows 32bit license.
Run ReactOS as headless i.e without the UI, as a guest inside a VM on a 64bit host. The host must have Intel Vt-d I/O (or equivalent / IOMMU) on both its motherboard and CPU for the guest OS in the VM to be able to see the hardware in the host.
As a kernel engineer Mr. Reitshin will know that a kernel consists of a number of functional components that perform well defined functions. Any kernel (e.g. from that Reg article about Fuscia one can derive quite a lot of information about the structure and implementation of that kernel). So expecting these components to be unique is a bit much. There may be substantial differences in the implementation but the basic idea will stay the same.
I think he's got "Microsoftitis", that disease of the mind that's caused by viewing the various components and subsystems of a computer as a homogeneous entity. Microsoft in particular has never really figured out how to abstract a GUI -- something that's really an application -- from an operating system. He could learn a lot from Linux, in particular how you can change around kernel components such as schedulers and so learn that while the principles are relatively unchanging the implementation can vary considerably from implementation to implementation.
The claim anyone would steal anything from Microsoft is absurd, because Microsoft never created anything.
Windows was junk until Digital Equipment Company, DEC, went under, and Microsoft hired its programmers.
Everything good or interesting about Windows, like COM and DCOM, came from stealing from DEC.
Before DEC employee were hire, Windows could not even pre-emptively multi task.
IIRC, about the time Microsoft released its Windows Research Kernel, there was a big discussion on the ReactOS mailing list about what people should do about it, particularly if they were students at a university that used it. Or were in any way exposed to it.
I had been commenting on the Groklaw blog for a while, ever since I found it, and I recommended that the MS WRK be treated as "reading material", in other words, treat it the same as the BSD CSRG treated the AT&T Bell Labs Unix source trees - which they had a legal right to see, since the University of California was a licensee of the original Unix source code. According to Peter Salus, A Quarter Century of Unix, people at BSD Unix gatherings would cheer when someone from the CSRG would inform them that one more file had been rewritten and was now unencumbered.
It sounds like they might have taken my advice.
It's worth mentioning that nowhere does Axel Rietschin in his posting on Quora allege that anything more than "internal data structures and internal functions" having exactly the same names as the WRK. He presents no evidence that the ReactOS internal functions are exactly the same as the WRK. And the reasoning behind keeping everything named the same and returning the same values, etc, is that Microsoft on more than one occasion wrote their applications to call such internal functions, in order to give the Microsoft applications a speed advantage over non-Microsoft applications. Anyone remember the farcical Internet Explorer as part of the MS Windows OS testimony during the anti-trust trial? If you want to run the same software at the same rate of knots, then you have to react the same way.
Biting the hand that feeds IT © 1998–2019