Steven Edwards On The Future Of ReactOS And Wine 157
Alex_Ionescu writes "WineHQ brings us the scoop on the latest developments in ReactOS, as well as on Steven Edward's excellent job on porting Wine to MingGW and linking the two platforms together. This is an interesting insight into the WINE and ReactOS project, and a must-read for anyone interested into the future of Windows-replacement projects like these."
Why clone Unix? (Score:5, Insightful)
Second, Unix systems have been established a track record of power and reliability (yes, there have been very bad Unixes, and they tend to have been removed from the marketplace). Windows
Windows is changing rapidly, in ways that are likely to make programs incompatable with older versions (the better to force upgrades with, I'm sure). I'm sorry, but if after 7 years of work the project is almost within grasp of being able to use a DHCP client, I don't see any way they can keep up with Microsoft. If they want to work on it as a hobby and have fun doing so, more power to them. I just don't see it as being something overly useful. Screenshots of minesweeper (with poor graphics) aren't what I want to see. I want to see a version of Group Policies, Active Directory capability, and so on.
*BSD and Linux suceeded, not simply because of price, but because they were *better* in various ways than the competition. Microsoft has a tremendous software and driver collection, and has begun to do some really cool stuff. OS X has a simple UI that many people adore. What does ReactOS bring to the table, if it's three generations behind Microsoft? DR-DOS was cheaper and better (IMO) than MS-DOS, but Microsoft still ground it underneath their boots.
Re:Why clone Unix? (Score:5, Insightful)
I would say two things
1) an open source code.
2) as part of thier developement process thier creating usefull tools and info to help developers of windows software port to linux, or even write code that easily ports from one to the other.
The reason Dr. Dos and other failed was in part do to the fact that it depended on income to succed and thus could go belly up financially. Much harder for an open source project do that.
Also Microsoft wrote code in thier apps that generated false error messages in some dos replacements, giving the false illusion that the dos replacement was buggy or incompatable. FUD wasn't used because microsoft was feeling sadistic, it was used because it worked.
Of course one of my favorite reasons for writing any open source/freeware code is 'why not?'
Mycroft
Re:Why clone Unix? (Score:2, Offtopic)
Sheesh look at the number of 'first posts' it caused.
Mycroft
Re:Why clone Unix? (Score:2)
50% Offtopic
50% Interesting
Extra 'Offtopic' Modifier 0
Karma-Bonus Modifier +1
gotta agree with the mods here, amusingly enough.
Mycroft
Re:Why clone Unix? (Score:4, Informative)
The message was only present in *beta* versions of Windows 3.0, and was non-fatal. It was not present in the released version.
DR-DOS 6 actually did not emulate some internal data structures Windows 3.1 used, and would cause Win3.1 to crash under certain conditions. These problems were corrected in a patch which was released ~6 weeks after Win3.1 came out.
Re:Why clone Unix? (Score:5, Informative)
This is what's known by historians as a primary source.
Re:Why clone Unix? (Score:2)
Yes, the message still existed in win.com, but it was not shown on retail releases of Win 3.1 running on DRDOS. Thank you for clarifying because I've been saying for years that I thought I remembered running Win 3.
Re:Why clone Unix? (Score:2)
"[...] the retail version of Windows 3.1 doesn't produce it, [...]"
Re:Why clone Unix? (Score:1)
Re:Why clone Unix? (Score:2)
Re:Why clone Unix? (Score:5, Insightful)
2. Open source may not need money to survive, but it does require "the itch" that causes the programmers to scratch. Remember, writing the software is the easy part. Testing the code and making it bulletproof is the hard part. I've seen many open source projects get 90% done and fall apart because they find that there just isn't that much consumer interest in it, and there wasn't the motivation to get over the hump of sitting there are 2 in the morning trying to track down that memory leak that seems to only happen every 27th time a function is called.
As far as DR-DOS, what makes you think that if ReactOS were to actually threaten MS, what makes you think they wouldn't squash them through use of FUD, patents, or other such measures? Given that MS Office is still 'the killer app' for offices, I doubt it would take much code to make it develop mysterious errors when running under ReactOS.
Other than the fun-for-the-programmers aspect, I'm still just not seeing the target market for this. With home users, either they need the absolute basic stuff (word processor, e-mail, spreadsheet, browser). I suspect that by the time that ReactOS is finished and stable, there'll be cheap Walmart or AOL branded Linux boxes that fill that role nicely. Home users looking to play games won't be interested, because modern games will be so far above what NT can handle. (I suspect that MS has more people working on DirectX alone than the entire ReactOS team.) And most business users will shy away from anything that's not heavily tested. My employer provides me with a copy of VMWare and WinXP, because it's far cheaper to purchase those than to have me burn hours futzing around with a first generation cloned OS.
So we're back to "why not," which I think is a better answer than, "why clone Unix?"
Re:Why clone Unix? (Score:2)
I honestly think one of the best outcomes of this project is the knowledge and tools gained that can make Linux a more attractive target for developers, or at least an easy port target. Getting the software on open/free software is a significant hurdle to mass consumer acceptance (assuming that matters to you) and making it easier to devlop/port and run would a major plus in that regard.
As far a rigging office is concern
Re:Why clone Unix? (Score:1)
If they implement all the low-level stuff well, it seems to me that they could easily use the MS binaries for DirectX compatibility.
-----
Which would require having a Windows license, which would seem to defeat the purpose.
Re:Why not, indeed? (Score:1)
When I think of a rant I think of an endless tumble of angry words, not the hazy fumblings of a couchrider coming down.
Re:Why clone Unix? (Score:1, Interesting)
No, the reason DR-DOS failed is because it is *DOS*. By the time it became popular (the DR-DOS 5.0 days) it was already irrelevant.
Re:Why clone Unix? (Score:5, Insightful)
it snowballs my friend. It is a slow rolling snowball, but it grows and grows and grows.
Re:Why clone Unix? (Score:5, Interesting)
TCP on the other hand is really complex.
OG.
Re:Why clone Unix? (Score:2)
Re:Why clone Unix? (Score:3, Insightful)
Well, once ReactOS development gets to an advanced enough level, I'd be able to play some of my favourite games without having to boot into Windows.
I'm not as concerned with commercial viability as I am with the ability to run Windows programs without having to use a proprietary OS. Whether or not it's a commercial success is really irrelevant. Look at Linux--it's nowhere near as commercially viable as Windows (and I'm not
Re:Why clone Unix? (Score:2)
So in other words, it does not really bring anything to the table.
Re:Why clone Unix? (Score:2)
OTOH, building a Windows clone (ReactOS) and *then* trying to emulate it in user-space might be easier than trying to emulate it right away (Wine), especially when you want bug compatibility.
Re:Why clone Unix? (Score:1)
Okay, I'm following you so far...
HELLO! You already explained exactly why this is useful. In 10 years, when I want to run some "ancient" program that doesn't work with the latest version of Windows, I'll either have to dig
Re:Why clone Unix? (Score:3, Interesting)
No, Unix was never cloned at all... at least not in the same sense that ReactOS is a clone of WindowsNT. But then again, Unix isn't even a piece of software. UNIX(tm) is, however.
ReactOS aims for binary compatibility with Windows (it barely works, but that is their goal). Linux and BSD not only lack binary compatibility with UNIX, they don't have complete source code compatibility either- and their maintainers don't want to add it, considering some old UNIX way
Re:Why clone Unix? (Score:3, Informative)
And IIRC, NT didn't support DHCP until 3.5 (nov 1994?), but I could be very wrong about that. My memories of NT's early days are getting hazier and hazier.
As cool as the concept of ReactOS is... (Score:4, Insightful)
Re:As cool as the concept of ReactOS is... (Score:2, Funny)
I wouldn't be suprised to see it spark a national security investigation over the gathering threat these FS/OSS terrorists pose to our way of life!
Re:As cool as the concept of ReactOS is... (Score:2)
Hmm...as much as many Slashdotters think that some ``anti-terrorist'' crusade against OSS is going to happen (over something, if not this--people have brought this up numerous times in various comments to earlier articles), I very seriously doubt it'll happen over something like this.
IMO, it would take something really big, like some kind of OSS-based attack
Re:As cool as the concept of ReactOS is... (Score:4, Interesting)
What the parent poster, and all other posters (me included) that associate OSS with terrorism, being un-American, a hippie, a communist, etc. Is using it as sarcasm, as if they were posting directly to those companies who are saying such things.
ie:
SCO: "Linux is unAmerican and is a terrorist threat to national security"
LZelot: "Ohhh, Well I guess there is going to be a big national full out anti-terrorist investigation, and a $100000000 bounty on all penguins"
SCO: "See, even the zelots agree"
Re:As cool as the concept of ReactOS is... (Score:1)
Absolutely classic trick of the trade - appeal to all comers by keeping the monster vague, avoid any response by leaving the "not them" door open.
I'd congratulate you if you didn't sicken me.
Re:As cool as the concept of ReactOS is... (Score:2)
Re:As cool as the concept of ReactOS is... (Score:2)
Lets not do anything, because we'll loose anyway. Some idea like don't leave your house, the day will be shitty anyway.
Re:As cool as the concept of ReactOS is... (Score:2)
I never said anything of the sort. I said there was a risk, I never said it was an unacceptable one. I made another comment elsewhere on this article, which supported ReactOS.
Just because I worry about something, doesn't mean I'm paralyzed with fear or that I want others to be.
Thanks... (Score:5, Interesting)
Good progress (Score:5, Informative)
Re:Good progress (Score:4, Funny)
A Canadian project, is it?
A perfect name (Score:5, Funny)
Hey, why not call it that? "Port"! I dunno if renaming a port is unusual, but if so I think we can make an exception in this case.
He plans to start using it within a year. (Score:4, Insightful)
That's a pretty big step.
Wonder how long before it's ready for gaming?
Re:He plans to start using it within a year. (Score:2, Funny)
Hats off to the ReactOS crew. I'm glad to be proved wrong on this one.
MingGW? (Score:5, Funny)
Would that be the Chinese version?
Re:MingGW? (Score:1)
t
Re:MingGW? (Score:1)
No, silly. That would be the Flash version, Oh Ooooooh! King of the impossible. He'll save every one of us.
KFG
Why? (Score:5, Interesting)
Perhaps starting from scratch (ReactOS) is easier than the writing the middleman layer (Wine), which is still playing catch up after many years?
(Any flames was unintentional. I would love for either project to succeed, I just want to know their merits)
Re:Why? (Score:2, Insightful)
You don't see the merit in an open source version of Windows?
Re:Why? (Score:1, Insightful)
LOL! Agreed...yeah, maybe it would be trust worthy? On that, oh, let me count the ways;
Auditable
Securable
Maintainable
Customizable
Every default desktop on Windows seems to have about 3 dozen advertizements and promotional icons and menus for crap.
An open source version of Windows could be lean an mean.
Getting rid of the crud and crap that seems to be layered on Windows is nearly impossible. Once it's on a system...how do you know
Re:Why? (Score:1)
If you're going to be paranoid, do it right.
Re:Why? (Score:1)
*sighs* Who can fathom the mind of the geek?
Re:Why? (Score:5, Interesting)
You look at Windows and you think "past" and "legacy". We (ReactOS) look at Windows and think "future" and "innovation"
This you say is (my personal opinion, not the project's official position), a lot like people deluding themselves in thinking that a Linux kernel for the next Windows would mean instant improvement. If you knew a bit more about Windows you'd knew it doesn't even make sense - the Windows kernel has proved to be a sound design and I'd be happy if we could at least duplicate it. It's the system services that need a serious redesign, dragging the legacy microkernel corpse as they are, and I'm already doing some research in that direction (currently reimplementing the console model to be driver-based instead of server-based, and allowing custom UI implementations. This will give you, the user, custom terminal emulators, a more efficient SSH server and a job-controlling shell - even a port of your beloved GNU screen. Next stop: overhauling the service manager and rationalizing the user-mode startup sequence)
And please realize that a supposed intrinsic and purely technical superiority of Linux exists almost entirely in your mind - old kernels (2.4 and earlier) weren't that hot, and when you say "Linux" you generally mean "GNU" (those who say "Linux" meaning "Beowulf" or "OpenMOSIX" are the minority) - and realize that "commodity" also means "largely irrelevant" and "expendable" - when ReactOS gets good enough, it could replace even Linux for some people
Re:Why? (Score:1, Insightful)
A modern Windows can't.
Is that some technical superiority that "only exists in [my] mind"?
Otherwise, good post.
Re:Why? (Score:2)
Good luck on ReactOS it is interesting and I hope a lot of fun.
Re:Why? (Score:4, Informative)
This is more of a case of options, rather than why one is better than the other. As was mentioned clearly in the interview, ReactOS and Wine are working together, and there is quite a bit of mutual support they can give each other. It is not one or the other, but rather many efforts can help both projects at the same time. In fact, as Wine is moving to support more Windows applications, it is necessary to work with even more kernel services.
These two projects are attacking the same problem, but from different directions. This is why the cross-pollenation efforts are even more valuable, because each group sees a different set of problems and finds good solutions often when the other group isn't quite looking there yet.
In terms of re-inventing Windows, this is the only group that I've seen that has succeeded. There have been other groups in the past that have tried, but almost all of their efforts have been folded into ReactOS in terms of active developers and design ideas. The unsung hero with all of this is Jason Filby, who has done a remarkable job of keeping this project going through litterally years of effort when even a command prompt was not available. He is the driving force that is keeping everything together, and a very approachable person as well. When this project succeeds, he is certainly somebody who deserves strong kudos from the open source community.
Why a free software version of Windows? I think this will be very important to think about when Longhorn comes out, but Microsoft show little to no support for legacy applications, and is more than willing to abandon platforms when it serves their purposes. This is a matter choice, and this project will give more options, not fewer.
If you are not familiar with the NT kernel, there really is some amazing architecture that from an OS viewpoint should be studied. It is more like the difference between a GM engine and a Ford engine (for those few amature auto mechanics out there who know what I'm talking about). Each has it own fans and critics, but comparing Unix to NT shows some significant design choices in the basic fundimentals of the operating system. Microsoft has muddied up the picture in part because there hasn't been (until ReactOS) an independent implementation of the NT kernel or with the exception of Wine an implementation of the Win32 API library.
This really is more the debate of propritary vs. open source, which is probably why this news posting on
If you want to see something really neat, try and get ReactOS running with Mono. Mono is aiming more for Linux compatability right now, but with ReactOS handling some of the Windows API issues, ReactOS+Mono will run many of dotNET applications that won't run under Linux. All of the command-line Mono development tools will currently run in ReactOS, and I think this is another untapped combination that hasn't really been followed.
Re:Why? (Score:2)
Re:Why? (Score:1)
Probably will hit 1.0 a year after Duke Nukem (Score:4, Insightful)
Wine is almost 10 years old and yet to ship a 1.0. And already bitrotting away because parts are still win16 (from reading the article) because they were coded pre windows95.
DOSEMU did eventually ship their 1.0 version... and was promptly deleted from the RH disks in the next rev as obsolete. It 'succeeded' because they were cloning a dead OS that didn't keep changing. If you count success as finishing long after it would have been widely useful.
Now we have ReactOS cloning Windows NT4. And will perhaps get it 90% feature complete in another few years. And then spend the next half decade completing the remaining 10% by which time NT4 will be so obsolete nobody will care. Of course they are already trying to shift their target to NT5.1 (XP) but like Wine, they just can't code as fast as the infinite monkeys at Microsoft.
As for their retort of "Why clone UNIX?" I have an easy answer. Because it is USEFUL. Microsoft's stuff isn't worth cloning and by the time a clone is finished they will have either won, forcing everyone into a DRMed hell where only their signed OSes even boot or we will have made them moot.
Re:Probably will hit 1.0 a year after Duke Nukem (Score:2, Interesting)
Re:Probably will hit 1.0 a year after Duke Nukem (Score:3, Interesting)
> base on a libre os.
Don't see it. Wine has been trying for ten years just to get the Windows APIs recreated. So lets assume these guys get to 1.0 by 2009, five years from now. How much Windows NT 4.0 software do you expect anyone to be itching to run in 2009?
> point is porting to windows proggys to it will be trivial
Winelib is already feature complete enough to port most Windows proggys. Haven't seen em busting down Code
Re:Probably will hit 1.0 a year after Duke Nukem (Score:3, Insightful)
Not to be faecetious, but who cares? I mean, who cares who writes the drivers, or whether they even get written? Oh, did you think Free Software was about convenience?
If you did, you are seriously missing the point here.
Free software is about freedom. Windows gives us none. Personally, I'm not much fond of Windows. But lots of people like it a lot... I mean, they like its UI and its way of doing things. These people, if they believe in Free Software, have perhaps been forced by their idealogy t
Re:Probably will hit 1.0 a year after Duke Nukem (Score:5, Insightful)
> get written?
Kinda hard to boot without the basic device drivers. So yes, it is important unless the plan is to leach off of the Windows driver set and that really isn't the GNU way.
> Free software is about freedom.
Agreed. But just how much Freedom does one expect to find chasing Microsoft's tail lights?
> to OSIers, it's all about how useful it is...
Well it does need to boot and run programs ya know. That sort of fundamental functionality is what I'm questioning the ability to create in a useful timeframe. If DOSEMU and Wine are a guide, ReactOS will be more of a MAME/MESS sort of nostalgia trip. Don't see how that advances the cause of OS/FS other than increasing the skills of the developers.
> Maybe you're a new Linux user, or maybe you aren't one,
Examine the URL at the top of my posts. WIth a shrinking list of exceptions, my current working set of software would pass the RMSLint test.
> It was a pain in the ass, but we did it,
Hey, the first time I saw a blurb in Byte about Linux I had a boner for it. A year or so later I actually found a boot/root disk of
The point is that even ten years ago, a two column inch mention of serious work on a Free OS was more than enough to get me interested, but I just don't feel any such burning need for ReactOS. And I tend to doubt many others will either.
Linux was possible because of the decades of UNIX tradition, a published POSIX standard to write to, almost a decade of GNU's work before Linus ever wrote version 0.01, the X Consortium's codebase, etc. Where is the great body of enabling work that ReactOS is to draw from? How many Free Software types care about Win32 enough to write code for it? Hard enough to even get most to support Win32 as a port because Win32 is fugly and makes for messy code.
Re:Probably will hit 1.0 a year after Duke Nukem (Score:2)
That wasn't one of those Panasonic drives with its own driver card, was it? Aaach! What a mess!
Whatever the motivation these folks have for writing this particular piece of soft
Re:Probably will hit 1.0 a year after Duke Nukem (Score:2)
> was it? Aaach! What a mess!
Worse The controller was a Tandy custom job built by Creative Labs. Halfway between a SB Pro and an SB16. Creative/Panasonic CD interface but mapped at some totally oddball address and on a 16bit interrupt. The bitch was finding out where it was since the DOS driver specified the usual 0x220 or 0x240 base address of the soundcard and it just 'knew' that the CD port wasn't at 0x230 or 0x250 like it wo
Re:Probably will hit 1.0 a year after Duke Nukem (Score:2)
Think proprietary business applications which talk to proprietary business hardware with binary-only drivers.
Think about running these applications and hardware on a free operating system.
Then think about using the facilities of that free operating system to reverse engineer the hardware interface from the driver.
Then think about implementing a free business application which talks to that free driver.
Suddenly the f
Re:Probably will hit 1.0 a year after Duke Nukem (Score:1)
Yes, think about that. Think about Microsoft's approaching DRM Trusted Computing Initiaive, which will make it cryptographically impossible for a signed program to run in an unsigned OS.
Microsoft will soon be able to combine technical and political techniques to declare reverse-engineered Windows illegal. Then all the effort put to ReactOS will have been for naught.
In fact, Microsoft might hold
Re:Probably will hit 1.0 a year after Duke Nukem (Score:3, Insightful)
I ger a driver disk with almost anything I buy, including basic mice and keyboards.
The only things I haven't gotten drivers for are cables and standard floppy disk drives and a few oem cd-roms.
I even got a disk with an 80meg ata hard-drive.
Also why couldn't they port the linux drivers if they really wanted? Last few times I installed a linux distro it installed all drivers I needed painlessly and I didn
Re:Probably will hit 1.0 a year after Duke Nukem (Score:3, Insightful)
Re:Probably will hit 1.0 a year after Duke Nukem (Score:3, Insightful)
It runs more and more apps every day, but the developers haven't declared it 1.0 yet. I'll trust their assessment of the project's status over yours if you don't mind.
> It runs office if you want to,
With a lot of fussing it will, or a check to CodeWeavers.
> but why bother when it also runs star wars kotor (winex)
Or a check to Transgaming. But how much does WINE run? Not Crossover Office, not WineX, Wine itself. I haven't checked in on them i
Some disagreement... (Score:1)
I can see an NT/Win2K ( no, no, PLEASE not XP ) compatible OS as something that many companies and people will see as a way off the MS treadmill of "another new OS that doesnt do much more for me, but is going to cost me a bunch in new hardware and new OS licencing".
It would give them a low cost ( hardware costs, training costs ), low overhead ( retraining issues ) option. A lot of companies alre
Re:Probably will hit 1.0 a year after Duke Nukem (Score:4, Insightful)
> us within the coming year
No, according to the article, within a year ONE of the developers hopes to adopt it as his primary OS. Think about that a minute. Within a year it might reach dogfood status. Up to now it appears none of them actually run it much outside of emulation. That is a hell of a long way from being ready for the 'rest of us'.
But hey, like I originally said, it is an ambitious project and good luck to em. Don't really expect them to succeed but there will likely be some good spinoffs like a better Wine and perhaps some other useful code.
And how can you compare it to Hurd now having PPP? At least it has working ethernet and ReactOS is still working on a TCP stack. PPP really isn't all that useful anymore in case you haven't been paying attention.
But after defending the Hurd, might as well slag it a bit too and say that it is another product that is looking to be obsolete before initial delivery. By the time it ever gets finished I suspect Microkernels will be an outdated concept, replaced by some other impractical but fashionable trend in research OSes.
Re:Probably will hit 1.0 a year after Duke Nukem (Score:4, Insightful)
Huh? how do you figure the method most people use to connect to the internet isn't all that usefull.
Don't tell me you think most people have slip or adsl or home oc3's.
Mycroft
Usefulness of PPP (Score:2)
> internet isn't all that usefull.
Anyone hackish enough to be working on the HURD probably isn't using PPP.
I live in a rinkydink little town in Lousiana and am nowhere near leet enough to be working on the HURD and I haven't used PPP outside of hotel rooms since 2000. And even if someone is so unfortunate as to be forced to use a dialup, real hackers have home networks so only the gateway router needs to know PPP.
But this has wand
Re:Usefulness of PPP (Score:5, Insightful)
Oh and you don't have to be 'leet' to code, even on the big opensource projects. You just have to be able to code. That's the strength of open source anyone can spot somthing, anyone can write an answer. True 'leetness' (skill talent and experience) increase your versitility and odds of comming up with somthing really cool, but even the HURD and GCC and Linux need that four line patch to swap some bytes around on some obscure file format or device driver.
Don't buy into myth of 'leet' or 'real' hackers as all fitting some stereotype or other, that's hollywood talking. They fall into the same general mix of poor and rich and so on as anyone else.
Mycroft
Re:Probably will hit 1.0 a year after Duke Nukem (Score:2)
This poor suffering disucssion (Score:4, Interesting)
-----------
WAP [chiralsoftware.net] software
Re:This poor suffering DISCUSSION (Score:2)
Your response gives your alternate to Windows, but without more insite, users like me do not or cannot use it because my system already has Windows, and we don't know how to replace it without screwing up all that mail etc., that we have put there for the past 3-5 years.
The general Windows user might change over to linux with wine and crossover but only with help and wit
Huh? What? (Score:2, Insightful)
With Slashdot comments being offline, I actually read the article. The interview went on and on, but for the life of me I can't figure out the point of this. Wine [winehq.com] lets you run Windows software on UNIX platforms. MinGW [mingw.org] lets you run recompiled UNIX software on Windows. What could POSSIBLY be the reason for porting Wine to MinGW? That would let you run Windows software ON WINDOWS. You can already DO that! It sounds like they are trying to reduce dependencies on UNIX in the Wine co
Re:Huh? What? (Score:4, Interesting)
What wine already has would be usefull in the NON-UNIX environment they a building.
Now thier choices are to
a) remove the dependancies on *nix from wine, somthing mingw helps with.
b) recreate everything usefull in wine from scratch (re-invent the wheel)
c) add a unix emulator for an nt workalike that will support wine so that thier running a windows workalike on a unix workalike on windows workalike.
Which do you think is thier best option.
Mycroft
c) Port it to the hurd (Score:1)
What else could be more funny than running a WindowsNT emulator on a GNU/GNU Kernel
Now if I could figure out how to make the HURD provide the NT kernel functions, this post would make sense.
This has been done before (Score:2)
I also recall the ARP (AmigaDOS Replacement Project) for the Amiga.
All ReactOS seems to be is a replacement project to replace Windows. A better Windows than Windows, sounds like they borrowed that from OS/2.
ReactOS may not be worthwhile now for the average Windows user, but once Microsoft turns on us all and releases Longhorn that does not run Windows code, ReactOS may be
Re:Huh? What? (Score:2)
Maybe so you can test and debug your software on a single platform, and target it for multiple, making the development of cross-platform solutions easier? If I'm going to do a WineLib port, I imagine it would be very nice to see the native version running side by side with the WineLib version.
Re:Huh? What? (Score:2)
ReactOS isn't Linux, and so Wine won't run on it if it depends on things in every standard Linux distro. And it isn't a UNIX clone, so UNIX dependencies are a problem.
ReactOS is an attempt at a Windows clone. Rather than rewrite the whole Win32 API from scratch, they decided to use Wine as much as possible. So they're porting Wine to MinGW,
Windows drivers to linux conversion (Score:4, Interesting)
Re:Windows drivers to linux conversion (Score:4, Interesting)
http://www.jankratochvil.net/project/captive/ [jankratochvil.net]
This compatibility was achieved in the Wine way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations, on a case by case basis. Project includes the first open source MS-Windows kernel API for Free operating systems. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety.
I see where ReactOS could be REALLY useful (Score:5, Interesting)
What we really need for those PC104 and other small boards is an OS with the following features:
open-source and configurable
reliable and stable
small resources requirements
working from ROM
Win32 compatible, supporting DCOM and MS-style networking.
There is no need for DirectX, scanner support and such. It looks much like that despite Microsoft declares embedded systems support as one of their primary goals, they just do not know what to do.
WinCE is for PDAs, not for industrial systems.
Re:I see where ReactOS could be REALLY useful (Score:3, Insightful)
I personally don't see any real reason to use embedded NT in favor of embedded linux. Second can do it all cheaper, with less hardware requirments, and beeing more flexible, and over all it's Open Source thus giving you complete control over your product.
Re:I see where ReactOS could be REALLY useful (Score:2, Insightful)
I do. Most of the top-level software works under Windows (I mean in SCADA systems, not in stand-alone embedded systems). Control software, accounting software... It is much more effective to have two teams - one for embedded part, second for SCADA - that are speaking the same (Windows) language.
Things like OPC or NetDDE were developed for Windows.
Re:I see where ReactOS could be REALLY useful (Score:5, Informative)
The really nice thing about this is if you have components you are adding to an embedded system, and the manufacturer has Windows device drivers, ReactOS will recognize them and they don't even need to be recompiled. This opens up a whole range of equipment options that would not normally be available under embedded Linux (although most embedded equipment companies are supporting Linux now... this wasn't always the case).
I don't know what is cheaper than free software, and the point here is that this increases flexability. I don't know about what you mean with hardware requirement, but I don't see too many 386 CPUs anymore, even among embedded systems. ReactOS will run on most of the common CPU systems found in embedded systems, particularly if you are already looking at a Linux-based system as well. This is an option, not a requirement.
If you are talking about using the Microsoft version of the NT 4.0 kernel in an embedded system, I would have to totally agree it is a mistake. I would still be careful about the "uneducated developers" you are thowing stones at, because there is a huge difference between the NT kernel and Windows CE (which truly is for the clueless developers). On raw technical merits, I would stand behind an NT-based kernel as much if not more than a unix-based kernel (like Linux).
Re:I see where ReactOS could be REALLY useful (Score:2)
However I've recently seen some oscilloscopes running Microsoft Windows 95 and NT, we got several to evaluate. Almost all of the newer ones are constructed like this.
Honestly I'm really considiring this as stupid. Why can't they run Linux with X on such a Oszi-PC? Saves the license costs, and also keeps the Oszi from crashing (which the Agiland one actually did ocassionally).
Why Bother? Listen... (Score:1, Informative)
Once that upgrade addiction cycle is broken, can you see us
WineHQ screen shots (Score:4, Informative)
I had tried e-mailing some contacts listed on the site, but there has been no responce. Who should I contact? Thanks.
Re:WineHQ screen shots (Score:1)
Why clone NT4? (Score:3, Funny)
Steven Edwards (Score:2, Interesting)
Microsoft is almost out of the equation (Score:3, Interesting)
The way it's described in the article, soon, you'll have as high a probability of running Linux on ReactOS alongside your Windows apps as you will to running your windows apps alongside your Linux apps on Linux through Wine.
And all these projects share code and therefore testers.
Once more users and developers flock to these solutions, the level of quality will keep rising.
It really is going to be very interesting.
And probably nerve-wracking for Microsoft...
I really can't see where Microsoft's niche will be.
It's all about the servers (Score:2, Insightful)
Essentially, it will let a small company focus on their core business without having to spend time and resources to transition to a new platform.
To fork out $800 per server plus CALs can hurt a small business. With a free windows server, they don't have to change their legacy code, yet can still expand their business.
Several companies I wor
Will ReactOS be relevant at the time of Longhorn ? (Score:2)
Another point that I would like to raise is that Linux should adopt a subsystem philosophy, like Windows: a POSIX subsystem, a WIN32 subsystem etc. It would be much better than the current situation. Of course this could mean "goodnight simple Unix
Re:Will ReactOS be relevant at the time of Longhor (Score:2)
Will Longhorn be relevant at the time ReactOS 1.0 is released?
I can't even begin to tell you how many developers and companies are currently stuck at Windows 2000, in part because they don't like the "extensions" done to Windows XP. A few that have moved into XP may make that their last Microsoft OS as well. Just because it has the Microsoft logo on the distribution box doesn't mean everybody is going to jump up and down trying to get it.
Keep in mind w
Re:Will ReactOS be relevant at the time of Longhor (Score:2)
Long-term view of ReactOS (Score:2)
ReactOS would then become a fork in the development of Windows. That is all. ReactOS is probabaly going to become more and more Linux-like in terms of support for interfaces like GTK or Gnome, allowing Linux drivers, and running open-source applications. Much of this is already written.
As has been discussed elsewhere, ReactOS as an embedded kernel is particularly attractive right now. I need to play
Re:put Wine out of its misery... (Score:2, Insightful)
Re:put Wine out of its misery... (Score:1, Informative)
Re:Why would you want to clone UNIX? (Score:3, Insightful)
He's answering the question 'Why would you want to clone Windows?' by saying that it's analogous to asking Linus and/or RMS 'Why would you want to "clone" UNIX?'.
Re:What is .. (Score:5, Informative)
QEMU [bellard.free.fr]