Split(Fork) the shell from reactos

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

cruonit
Posts: 250
Joined: Mon Jun 29, 2009 12:57 am

Split(Fork) the shell from reactos

Post by cruonit »

Maybe it would be nice to make a reactos shell fork on github and post some instructions.
Many Windows 8 users don't like the new start menu so they could use the reactos replacement. This would maybe attract some developers on github in order to test, review and find some bugs in the repository.

So this could speed up the development and be a good marketing.

mrugiero
Posts: 482
Joined: Sun Feb 14, 2010 9:12 am

Re: Split(Fork) the shell from reactos

Post by mrugiero »

There are already more featured solutions for Windows 8.

cruonit
Posts: 250
Joined: Mon Jun 29, 2009 12:57 am

Re: Split(Fork) the shell from reactos

Post by cruonit »

http://www.classicshell.net/ ? it's open source

Classic Shell has been in active development for 4 years and has over 10 million downloads.

Versions before 3.9.0 are open-source. The source code can be downloaded from Source Forge.
http://sourceforge.net/projects/classicshell/

maybe it could be used to test the shell API (with explorer_new) but i think there are some API's that are Vista/7/8 specific

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Split(Fork) the shell from reactos

Post by Z98 »

Why would we use github when we already have our own SVN server and issue tracking system?

User avatar
EmuandCo
Developer
Posts: 4431
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: Split(Fork) the shell from reactos

Post by EmuandCo »

Classic shell IS for Windows 7 and 8. No use at all for us
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Split(Fork) the shell from reactos

Post by PurpleGurl »

mrugiero wrote:There are already more featured solutions for Windows 8.
But many don't want "features," they want the familiar Windows interface. Many didn't want 8 in the first place, but that was the only supported drivers they had or their machine came with it.

Anyway, I thought similar as the thread topic. Our shell could be forked and made available as a stand-alone. But it seems the underlying .DLLs will be where we need the most help.

As for version targets, I don't see why we can't do things internally closer to 7 on the top side, while still being XP/2003 compatible on the bottom side. I mean, still report 2003 and keep that look and feel, etc., but have some of the newer APIs and use them privately. For that matter, I don't see why we couldn't incorporate some of 8's security and performance enhancement without breaking current compatibility. For instance, the newer OS's shuffle their libraries on the premise that a moving target is harder to hit.

Win 8 also has the ability to use the system timer in a stateless manner. It seems we could get closer to that, but only make the newer way available to our own stuff, while keeping it available the old way. Or a compromise. Just track programs that reprogram the HPET, let them have what they want when they are actively being used, and then return to standard or stateless during any other time. But this sounds more difficult, and could be a later refinement and certainly not something to tackle any time soon.

What I'd like to see more now is real hardware work. Probably about 70% of the machines (with the correct CPUs and no vendor locking) won't be able to run us without an emulator or VM. Yes, the shell work is very important, as that will be something that has to be done eventually no matter what, and it will highlight lower level problems. Being able to run pieces of ROS under 2003 or higher certainly shows we are making progress. I'd like to see the USB related hangs cleared up for good, and I'd like to see multi-core support. I've read complaints saying Wine is much faster, but I believe most of that is driver-related. Comparing ROS without drivers installed to WINE with full, up to date Linux drivers, is not a fair comparison. Any Windows version seems rather slow just out of the box. Video is usually polled I/O under those conditions, and in a mode not designed for performance (just installing and troubleshooting), and the HDD might be PIO as well. But once the correct drivers are installed, the machine seems much faster. ROS may actually be more functional just out of the box when compared to Windows. I'm pleased with the shell progress and hope to see that reach a point of completion, and I'd like to see more hardware-related work.

User avatar
gonzoMD
Posts: 1053
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Split(Fork) the shell from reactos

Post by gonzoMD »

I like the idea.

Giannis is as far to show the classic menu but there are much more things as modern startmenu or more reactos specific things.

this is one thing which we could source out so why not? There is (sadly) a bigger bandwith on people who want a classic start menu on Win8 than ReactOS.

Classic shell is very big (also modified explorer, IE and so on) and this is only the start menu (the critical point on Win8) So I think this has potential.

erkinalp
Posts: 859
Joined: Sat Dec 20, 2008 5:55 pm
Location: Izmir, TR

Re: Split(Fork) the shell from reactos

Post by erkinalp »

PurpleGurl wrote: As for version targets, I don't see why we can't do things internally closer to 7 on the top side, while still being XP/2003 compatible on the bottom side. I mean, still report 2003 and keep that look and feel, etc., but have some of the newer APIs and use them privately. For that matter, I don't see why we couldn't incorporate some of 8's security and performance enhancement without breaking current compatibility. For instance, the newer OS's shuffle their libraries on the premise that a moving target is harder to hit.
Win 8 also has the ability to use the system timer in a stateless manner. It seems we could get closer to that, but only make the newer way available to our own stuff, while keeping it available the old way. Or a compromise. Just track programs that reprogram the HPET, let them have what they want when they are actively being used, and then return to standard or stateless during any other time. But this sounds more difficult, and could be a later refinement and certainly not something to tackle any time soon.
We are already targetting Windows 8(NT 6.3) on the userland, but we are far from reaching, on the kernel side, we are targetting Windows XP/2003(NT5.1+2). ASLR requires almost complete rewrite of the kernel level things(cache, MM, drivers which need DMA, etc.) We cannot support both NT5.x and NT6.x drivers. About HPET timing, reprogramming the interrupt timer is a way to prioritize data flow on the processor in contrast to control flow priorities.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Split(Fork) the shell from reactos

Post by Z98 »

Too many statements in this thread are making me cringe.

We are NOT currently targeting Windows 8 in any way, shape, or form. And there is no way to create "private" APIs/functions. The moment a function is implemented in a DLL, it's accessible, regardless of whether the API is documented or not. And as has been stated many times in the past, many of the functionality exposed in user mode in Vista and higher depended upon architectural changes and enhancements in kernel mode. You cannot have one without the other so the moment we formally choose to target a newer version of Windows in the user space, we must also change our target for the kernel. Finally, you cannot change timer behavior without consequence. When Windows 8.1 came out, the change in behavior of the timers caused a fair amount of grief for people who were highly dependent on timer behaviors.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: Split(Fork) the shell from reactos

Post by Webunny »

Z98 wrote:Too many statements in this thread are making me cringe.

We are NOT currently targeting Windows 8 in any way, shape, or form.
I would hope not. Many discontent voices about win 8, after all, and I'm not too keen on it myself.

No, XP or equivalent is just fine as a goal for now, and if anything further is needed, go for win7, I would say.

mrugiero
Posts: 482
Joined: Sun Feb 14, 2010 9:12 am

Re: Split(Fork) the shell from reactos

Post by mrugiero »

PurpleGurl wrote:
mrugiero wrote:There are already more featured solutions for Windows 8.
But many don't want "features," they want the familiar Windows interface. Many didn't want 8 in the first place, but that was the only supported drivers they had or their machine came with it.
Yes, that's for sure. Most people who want other than Win 8's interface don't want Win 8 in the first place. What does that change? Most people is also comfortable with Windows 7's way, and those other shells give you the option to work as Windows 7, and even to go as far as to work like XP. I don't think making a new solution for an already solved problem is a useful way to use the time. But anyone who disagrees is free to do it, I don't think anyone really needs to make clear that I'm noone to say what you do with your time.

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Split(Fork) the shell from reactos

Post by PurpleGurl »

Z98 wrote:Too many statements in this thread are making me cringe.

We are NOT currently targeting Windows 8 in any way, shape, or form. And there is no way to create "private" APIs/functions. The moment a function is implemented in a DLL, it's accessible, regardless of whether the API is documented or not. And as has been stated many times in the past, many of the functionality exposed in user mode in Vista and higher depended upon architectural changes and enhancements in kernel mode. You cannot have one without the other so the moment we formally choose to target a newer version of Windows in the user space, we must also change our target for the kernel. Finally, you cannot change timer behavior without consequence. When Windows 8.1 came out, the change in behavior of the timers caused a fair amount of grief for people who were highly dependent on timer behaviors.
By "private," I meant that we use it for *our* code. Yes, other software can use it, but it won't expect it there and thus won't. So we can use the new ones while the software uses what it expects. Thus a hybrid in compatibility. Sure, if other software knew the functions were there, it can use them. Some newer APIs can be shimmed, or older ones could be emulated. Either way. So what I am referring to is hybrid or informal targets, not formal targets.

Perhaps the part where I said it would be difficult and should not be a current priority got lost, and I said that to prevent such a reaction. Without going full stateless on timers, there is a compromise, and that is to reset it to a slower rate that uses up less interrupt time when such an app that requires it is not being used, and to put it back to where it was when such an app takes back up. Just having a multimedia program loaded shouldn't mean it has the right to dictate the timer for everything else. Sure, let it have what it wants when it is active, but no need to keep it at full speed. Such a change would be less disruptive than going stateless, and could still cut power consumption for laptops and improve performance. That is really why Windows 8 went to that, IMHO, to try to make it more laptop and tablet friendly.

Again, I like the shell work, and I also think we need to make this work better on real HW. That should be a priority as it would get more interested people, testers, and bug reports. We speak of catch-22, and the thing about "not being intended for daily use" is part of the reason why. So if the deep drivers and kernel stuff were fixed, the USB code didn't hang so many machines, and HAL did a better job of making up for differences in PC variations, there would be more people available to iron out the shell and other things. When it gets that far, a good updater would be nice. That way, those who have dual boot and stuff and already have ROS installed can try newer versions and subversions without reinstalling. It seems we need to make things more friendly for testers.

cruonit
Posts: 250
Joined: Mon Jun 29, 2009 12:57 am

Re: Split(Fork) the shell from reactos

Post by cruonit »

I have nearly 30(i think there are more) types of PCs(and few laptops) on my Faculty from Pentium3 / old AMD to i7/Xeon with different configurations. I am planing to do a testing/debug log on all machines(with a detailed hardware specification). I don't have much free time at the moment but i think i could do it in july.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Split(Fork) the shell from reactos

Post by Z98 »

PurpleGurl wrote:By "private," I meant that we use it for *our* code. Yes, other software can use it, but it won't expect it there and thus won't. So we can use the new ones while the software uses what it expects. Thus a hybrid in compatibility. Sure, if other software knew the functions were there, it can use them. Some newer APIs can be shimmed, or older ones could be emulated. Either way. So what I am referring to is hybrid or informal targets, not formal targets.
Allow me to present dynamic loading. It's a remarkably common technique in Windows development where developers load a DLL at runtime to determine if the functions they want are present or not, regardless of what is "formally" listed on MSDN. It's how people got into the guts of internal DLLs such as run32 and kernel32 and pretty much exposed all that functionality and started using them despite them not being documented.
PurpleGurl wrote:Perhaps the part where I said it would be difficult and should not be a current priority got lost, and I said that to prevent such a reaction. Without going full stateless on timers, there is a compromise, and that is to reset it to a slower rate that uses up less interrupt time when such an app that requires it is not being used, and to put it back to where it was when such an app takes back up. Just having a multimedia program loaded shouldn't mean it has the right to dictate the timer for everything else. Sure, let it have what it wants when it is active, but no need to keep it at full speed. Such a change would be less disruptive than going stateless, and could still cut power consumption for laptops and improve performance. That is really why Windows 8 went to that, IMHO, to try to make it more laptop and tablet friendly.
That sounds like a really good way to offer inconsistent behavior, wherein a program can't predictably determine the behavior of the timers because they "may" be dynamic or not.
PurpleGurl wrote:Again, I like the shell work, and I also think we need to make this work better on real HW. That should be a priority as it would get more interested people, testers, and bug reports. We speak of catch-22, and the thing about "not being intended for daily use" is part of the reason why. So if the deep drivers and kernel stuff were fixed, the USB code didn't hang so many machines, and HAL did a better job of making up for differences in PC variations, there would be more people available to iron out the shell and other things. When it gets that far, a good updater would be nice. That way, those who have dual boot and stuff and already have ROS installed can try newer versions and subversions without reinstalling. It seems we need to make things more friendly for testers.
The rate at which work gets done is dependent on available manpower. Having Giannis "prioritize" hardware related work is rather pointless when he has little experience in it. People can tell the project all they want about what is important, but doing so doesn't get work done any faster or significantly change the areas an individual developer focuses on.

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Split(Fork) the shell from reactos

Post by PurpleGurl »

Z98 wrote:Allow me to present dynamic loading. It's a remarkably common technique in Windows development where developers load a DLL at runtime to determine if the functions they want are present or not, regardless of what is "formally" listed on MSDN. It's how people got into the guts of internal DLLs such as run32 and kernel32 and pretty much exposed all that functionality and started using them despite them not being documented.
Again, what I was referring to as "private" were private use of newer Windows functions, stuff that is already documented, just for a newer target. Most 3rd party software just looks at the version and uses what is available to that version, unless I am mistaken there. But if they did see some Vista, 7 or 8 stuff, what would be the harm in them using them if they work correctly, and if other things are not expected which aren't developed yet? I didn't mean private as in making up obscure functions that others would be likely to use for undocumented reasons and then complain about when they are gone. We are not the trailblazers here, and yes, saying that makes me realize some of your motivation. If we went in changing things, then things would be as messed up as in Linux-land. Of course, that is okay over there because they have more users who are also coders. Windows and ROS are more for the more common people, those who simply want to put in the CD/DVD, add a couple drivers, and have everything work.
Z98 wrote:That sounds like a really good way to offer inconsistent behavior, wherein a program can't predictably determine the behavior of the timers because they "may" be dynamic or not.
Why would it be inconsistent if every time each program was active, things were put back where they were the last time they were actually being used. It is the multimedia stuff that uses this the most, and not all are the best "neighbors." What I'd like to see in the far future would be a number of options for tuning things past what is available for Windows, and also the ability to disable the extra tweaking options. (Maybe provide a batch reset tool for the dense folks who mess with the advanced options and then forget they set them and wonder why things are breaking.)
Z98 wrote:The rate at which work gets done is dependent on available manpower. Having Giannis "prioritize" hardware related work is rather pointless when he has little experience in it. People can tell the project all they want about what is important, but doing so doesn't get work done any faster or significantly change the areas an individual developer focuses on.
I wasn't saying he should, nor knocking the great success he made. Like I said, all that work had to be done sooner or later, and I am pleased with the progress there. What I said does show we need hardware-related developers and that they need contracts. It also means we need more volunteer testers. I could do that, but I won't make that mistake again. The last time I tried to help in that capacity, I got my head chewed off. If there was a more informal atmosphere of bug-testing available, I'd help in that capacity. Beggars cannot be choosers, and yet, the attitudes I've experienced in the past seems like everyone has enough help and that rules and form and being right all the time are more important than getting people's help in testing. The tester coordinator jumped on me the last time for no reason. I wasn't reporting 2 bugs at the same time as accused, nor was I giving unclear instructions. I only mentioned the missing icon in the report since clicking it would be necessary, and I told how to load explorer manually using 2 different methods. Unless there is a guarantee that will never happen again, I will likely never offer bug reports again. Likewise, when someone makes a thread to discuss them informally, someone nearly always jumps on them and tells them to use JIRA. If it is anything like how it was before the move to JIRA, I'd likely edit a wrong field and be jumped on for that. So forget me wanting to help test.
Last edited by PurpleGurl on Wed Jan 29, 2014 7:27 am, edited 1 time in total.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], irony and 6 guests