64-bit x64

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

64-bit x64

Post by hugo »

What are the plans/thoughts/ideas so far as 64-bit versions are concerned?

If an effort is made now to focus upon this as the primary platform, then you will leapfrog yourselves.

I really think that in two or three years max, 32-bit systems will be all but trashed, 64-bit will eventually become ubiquitous.

The hardware is almost the same price and as soon as some decent games emerge and the like, people will have NO reason to buy a new 32-bit system except for cost and the CPU is only a portion of overall cost.

It's dead easy (almost) to buy an affordable AMD 64-bit box with > 4G ram, but 32-bit windows cant (unless you tweek the VM design) run with > 4G physical memory to my knowledge.

I would say that this is the biggest potential drawback to the long term viability of the project I really do.

Take the 64-bit hit now (its mostly kernel and driver stuff anyway) and avoid the immense challenge of trying to do this later and retest tons of code.

Lets face it, as soon as you get Reactos "working" (whatever that target may actually be defined as) you will need to begin recoding much of it for 64-bit operation, so why bother?

Be warned, 64-bit systems are the wave of the future ignore it at your peril!

chorns
Posts: 29
Joined: Tue Nov 30, 2004 12:47 am

64-bit OS

Post by chorns »

Read up on the difference between RAM and virtual memory. 32-bit Windows does support more than 4GB RAM.

Even if you had a 64-bit ReactOS today, which 64-bit applications could you run on it?

Casper

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

I dont think I really need to read up on the differences, especially as there is no confusion over the two terms, not in my posting anyway.

For your information these are the limitations of physical memory (ram) for 32-bit windows:

Windows XP Professional 4 GB / 1 to 2 CPUs
Windows Server 2003, Standard Edition 4 GB / 1 to 4 CPUs
Windows Server 2003, Enterprise Edition 64 GB / 1 to 8 CPUs
Windows Server 2003, Datacenter Edition 64 GB / 8 to 32 CPUs

So you are correct when it comes to the latter two, but as you can see the first two will NOT support a physical address space > then 4G.

Your last question has the answer "very few" but I dont see the relevance of the question.

But if you did indeed have 64-bit reactos today, then one thing is for sure you WONT HAVE TO UPGRADE IT to support 64-bits, right now this is something that you will NEED to do, certainly after three years or so.

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

Incidentally, one of the reasons that having more physcial memory than process VM is a challenge, is simple, the CPU only has at most 32 address pins; so like it or not its somewhat difficult for it to address more than a 32-bit address into the memory subsystem; its a hardware issue.

Andrewm1986
Posts: 108
Joined: Thu Jul 07, 2005 4:08 pm

Post by Andrewm1986 »

Just so you know.

ReactOS would need to get its 32bit sorted first so that it could impleted something akin to WOW (windows on windows) for the Win64 which is what allows 32bit windows programs to run on a 64bit OS.

A 32bit compatable 64bit CPU (AMD64) running a PURE 64bit OS will NOT run 32bit applications without an emulation system.

ReactOS needs its 32bit to work first before they can even CONSIDER 64bit :)

User avatar
Jaix
Moderator Team
Posts: 838
Joined: Sat Nov 27, 2004 3:40 pm
Location: Sweden, Växjö

64 bit ROS

Post by Jaix »

Well, it is clear that we need 32 bit ROS, but As sure as we have ROS for XBox and POWERPC on there ways we will most certainly have ROS64 done by someone who is interested enough about the time when 64 bit applications is mature and exist on the market, now there is only MS software that support 64 bit what I know of (except some drivers).

I even hope someone will make the effort to port ROS to Motorola 68k platform (16bit) so I can run ROS in my Amiga 500.

Or in my Dell Axim X5

Or my Nokia 6600

Or my Firewall SurfingBird 66ix

When we have a working stable 32 bit ROS we will se ports in all directions just like LINUX everywhere from phones via firewalls to mainframes.

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

You are quite right that WoW64 requires some thinking about I won't deny that.

But WoW64 (to all intents and purposes) is more or less an environment that supports the expectations of Win32 executables.

The OS "proper" has no 32-bit support as such, for device drivers or anything, "all" it provides is Win32 API emulation (for want of a better word).

So some of the work you are doing on 32-bit will have to be thrown away, the device driver area, the virtual memory manager, HAL and many other parts are useless and do not require emulation.

Only Win32 (more or less) requires the emulation "layer".

The x64 even has a mode that allows it to operate on a per-process basis, in a "pure" 32-bit "legacy" manner, whether WoW64 uses this I dont know.

Im not saying its trivial but I am saying this, that you are right about 32-bit being needed first, but it is only SOME 32-bit.

H

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

You are quite right that WoW64 requires some thinking about I won't deny that.

But WoW64 (to all intents and purposes) is more or less an environment that supports the expectations of Win32 executables.

The OS "proper" has no 32-bit support as such, for device drivers or anything, "all" it provides is Win32 API emulation (for want of a better word).

So some of the work you are doing on 32-bit will have to be thrown away, the device driver area, the virtual memory manager, HAL and many other parts are useless and do not require emulation.

Only Win32 (more or less) requires the emulation "layer".

The x64 even has a mode that allows it to operate on a per-process basis, in a "pure" 32-bit "legacy" manner, whether WoW64 uses this I dont know.

Im not saying its trivial but I am saying this, that you are right about 32-bit being needed first, but it is only SOME 32-bit.

H

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

You are quite right that WoW64 requires some thinking about I won't deny that.

But WoW64 (to all intents and purposes) is more or less an environment that supports the expectations of Win32 executables.

The OS "proper" has no 32-bit support as such, for device drivers or anything, "all" it provides is Win32 API emulation (for want of a better word).

So some of the work you are doing on 32-bit will have to be thrown away, the device driver area, the virtual memory manager, HAL and many other parts are useless and do not require emulation.

Only Win32 (more or less) requires the emulation "layer".

The x64 even has a mode that allows it to operate on a per-process basis, in a "pure" 32-bit "legacy" manner, whether WoW64 uses this I dont know.

Im not saying its trivial but I am saying this, that you are right about 32-bit being needed first, but it is only SOME 32-bit.

H

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

You are quite right that WoW64 requires some thinking about I won't deny that.

But WoW64 (to all intents and purposes) is more or less an environment that supports the expectations of Win32 executables.

The OS "proper" has no 32-bit support as such, for device drivers or anything, "all" it provides is Win32 API emulation (for want of a better word).

So some of the work you are doing on 32-bit will have to be thrown away, the device driver area, the virtual memory manager, HAL and many other parts are useless and do not require emulation.

Only Win32 (more or less) requires the emulation "layer".

The x64 even has a mode that allows it to operate on a per-process basis, in a "pure" 32-bit "legacy" manner, whether WoW64 uses this I dont know.

Im not saying its trivial but I am saying this, that you are right about 32-bit being needed first, but it is only SOME 32-bit.

H

Andrewm1986
Posts: 108
Joined: Thu Jul 07, 2005 4:08 pm

Post by Andrewm1986 »

wow hugo, stuttering 3 times. Think you need to see a doctor!

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

As for 64-bit apps being available in the market etc.

Rest assured there will gradually emerge a proliferation of apps for XP 64, a steady stream will indeed emerge.

My position is recognize this NOW and get moving, if you wait like 18 months and then say "Oh hey, look there are lots n lots of apps, databases, games coming out that require Win 64, lets go"; then you will have a big big time lag on your hands.

I guess this all boils down to how far behind (in terms of time) the ReactOS team are willing to be with respect to MS features, this is a pertinent question.

I mean would they be satisfied if they had a Win NT 4, 32-bit version that was very very good and ran all stuff that the "real" one could, but that only gets finished in 2010?

Would that be acceptable?

I mean there has to be a cut-off point beyond which equalling something is no longer relevant, because the thing it equals is ancient history, a distant curiosity.

This is my real cocnern with all this, I was invited some years ago by the guys here to participate in this (I have some decent experience and have developed compilers and stuff).

But I was never really satisfied, personally satisfied with either the precise goals or the timescales (or rather lack of any) and that made the whole project very unclear to me.

I'd like to see a detailed project plan, even just a task list would do, that identifies all the features and functions that ReactOS must support and see just how many of these have actually been coded, reviewed, tested etc.

In the cold light of day, it may turn out that like 10% has been coded, 7% has been tested and that this has taken four years, if so its not hard to extrapolate how long it will take to complete; I see nobody paying any attention to this, and when I and others raise it, its gets brushed off.

H

Andrewm1986
Posts: 108
Joined: Thu Jul 07, 2005 4:08 pm

Post by Andrewm1986 »

That is the problem with any open source application.

There are defined goals from individual people around the wiki, but not group goals.

This would be useful, i agree.

If anyone has seen the mono website they have a treeview of all of hte namespace and functions, with compleness next to them.

The same would be VERY useful for all of the win32 dlls, so that a developer could register and say "i am developing THIS function", and it would show as in development.

hugo
Posts: 12
Joined: Tue Jan 11, 2005 10:45 pm

Post by hugo »

Yes this is exactly what I mean; I havent seen the mono website, but from what you say, this is exactly the kind of thing ReactOS needs.

It could also include (here I go, getting excited!) some kind of dependency structure, where this makes sense, so that a developer could see right away that x and Y cant really be tested without Z, so he could choose to go to work on Z etc.

Your DLL suggestion is very good, for each DLL, it could be broken down into functions.

This would be a great help, and the tree could inlcude the names of the people who have worked on each DLL or even function.

Any competent ASP.NET developer could build such a site, even with VS 2005 beta 2 !!

H

Andrewm1986
Posts: 108
Joined: Thu Jul 07, 2005 4:08 pm

Post by Andrewm1986 »

I could do it using php. I have the source code for something simalar on my website


www.compendiumonline.info

look at view tutorials.

Anyone interested in helping me with making this for reactos?

Post Reply

Who is online

Users browsing this forum: DotBot [Crawler], Google [Bot] and 3 guests