Thread: Gnome on Windows (Green Gnome , Cygnome ,WinGTk)

As name implies this thread is on running gnome on windows. Currently many applications like deluge, evicee.t.c an be run ot windows.
There are many places you can found them but two major places for running Gnome on windows is:
1.CyGNOME. this project features porting of applications by making them on Cygwin. many of applications are available like gimp , gnome desktop 1.4 and development tools like glade -0.65. Works for Cygwin GNOME 2.x has started.

2. Green Gnome:This project aim is to run Gnome on windows and removing windows look and feel. But it don't port gnome applications natively.
3.Wingtk: this project ports many developers tools.
4.GIMP and GTK+: It ports applications natively.

All in all CyGnome is the most advanced and if you want to run a certain app then type it on Google with windows word and you will get the solution.

Good information, Luke. Rep++

Since the topic interests me lot, actually I've got many questions based on gnome and gtk for windows/reactos and freedos:

Questions regarding the cygnome:

1. Does the cygnome also come with nautilus filemanager in this ntos environment?
2. Can the cygnome run on a) windowsxp b) windows7 and c) Is it possible that the cygnome be made to run on reactos too in the future?
3. Does cygnome require cygwin to be installed, or it simply has an inbuilt cygwin runtime like the kde's emergence from kde-cygwin?


Questions regarding the cygwin, gtk and qt for path to independence from proprietary win32-extensions:

5. Does the cygwin depend on win32's api (C:\windows\system32 and C:\reactos\system32) for its running? can it be made as an independent substitute? can c-language (and pascal) invoke graphics in windows without requiring the windows.h header file?
6. Can a new extension of the gtk and qt be developed for freedos' x11 (opengem-extensions) from the C:\freedos\gnu\gcc.exe and C:\freedos\gnu\g++.exe compilers respectively, like the win32-extensions such as gtk-wimp and qt-win32 respectively?
7. Can the cygwin be made to run on the gem's api (api of opengem desktop under the C:\freedos\opengem\gemsys)?


Questions regarding the greengnome's starting point (since currently it appears to be an alpha stage replacement for windows' desktop shell which appears to begin as desktop on win32 -- but might emerge out as a separate ntos like windows and reactos):

8. can the greengnome also be made to run on top of the kernel32.dll of the windows' clone reactos too in the future?

9. greengnome is written from lazarus (freepascal) can it be made dependent on the gtk-wimp from the gtkfp (gtk2pascal) extensions contained in the lazarus framework instead of the dependency to the proprietary native win32-extensions which the delphi based sharpenviro-desktopshell and ultraexplorer-filemanager uses?

10. can a new extension of the greengnome be developed from freedos' x11 (opengem-extensions) from the C:\freedos\freepascal\fpc.exe compiler, like the win32-extensions such as delphi?

11. to fulfil the requirements of installability of the windows based .exe and .msi files of the msiexec (msi-installshield+regedit) -- i.e. a registry-write installer system for all ntos:

a) does the greengnome have to be as much wine-bound as its counterpart reactos, or it can be made slightly less wine-bound?
b) can greengnome use an inbuilt freedos-shell instead of msdos-shell which the reactos uses without changing wine-compatibility?
c) if greengnome were developed from fpc's opengem-extensions, can the proprietary IISServer based .dll extensions be replaced with the foss ApacheWebserver based .so extensions (or xitami's .xti or abyss' .abs) without affecting the installability of .exe and .msi files?

12. I'm looking for updates of cygnome/greengnome but not able to get newer than those of 2009. I hope they are still active.

xxx---xxx---xxx---xxx---end---xxx---xxx---xxx---xxx

My perception regarding Gnome as compared to Windows

1) Our program applications uses tool-bar and menu-bar on top of the application-windows for which the gnome's task panel's location on top is in continuation with the trend.
2) Windows's task panel's location on bottom is in discontinuation of the trend seen upto the application-windows level -- but unfortunately we often think it as perfect because we have become too familiar with it -- but anyway it is different perception for different users.
3) Gnome's tray panel's location as separate and on bottom is like that in windows, which I think can be made to look as good as the aqua desktop macosx -- because it appears that windows might slowly emulate some osx based panels like the clock, calender, etc. The examples of the other professional desktops of today are aqua (macosx), windows (windows) and a customized-e17 (gOS), which gnome3.0 has the potential.

My understanding regarding opensource widget based alternate-desktopshells as compared to native msforms based windows-desktopshell:

1) shells using native msforms-win32 based control interfaces: windows (win32-c/c++, vs frameworks), emergedesktop (win32-c/c++, mingw frameworks), sharpenviro (win32-pascal, delphi frameworks), some lxde(x)

2) use of the gtk-wimp gui control interfaces instead of the native msforms-win32:

a) If the gtk-wimp is directly from win32 (gtk-wimp), it is an lxde (win32) (like reactos (gtk+/gtkmm, mingw framework) and greengnome (gtkfp, freepascal framework)),
b) If the gtk is from cygwin then it is either a cygnome or cygwin-xfce depending on the compiler tools used -- c, c#, python, etc (gnome), c, c++ (xfce).
c) Currently emulation of windows-desktopshell with opensource widget panels is successful to only the lxde (win32) level in the form of various alternate desktopshells from blackboxes ((bblean, xoblite) -- fltk), reactos, etc.

3) Shells requiring conversion from msforms-win32 to gtk-wimp for running on reactos os kernel: EmergeDesktop (into gtk+/gtkmm, from same CodeBlocks IDE), SharpEnviro-DesktopShell (into gtkfp, from Lazarus IDE), UltraExplorer-FileManager (into gtkfp, also from Lazarus IDE) into ReEmergeDesktop, SharpROSEnviro and UltraROSExplorer respectively;
This is from the understanding that Lazarus is to Delphi the same way as MonoDevelop is to VisualStudioDotnet (c#) or CodeBlocks is to VisualStudio (vc++) or eventually Reactos itself is to Windows;
So whatever has been developed in delphi can be made cross-platform with lazarus plus replacing the msforms with gtk based oops interface.

4) Despite the regarding of reactos as an opensource counterpart of windows, both of them share the same proprietary msdos shell;
It is here that greengnome can hopefully improvise upon a step still further by using the freedos shell instead of msdos shell and thus impart some of the opensource controls which can have extensions from the freedos' set of tools such as gcc, g++, fpc, etc which they have provided for the opensource developers -- and yet freedos is unfortunately left out as much less utilized than what it deserves from this facility that it has provided, losing to even msdos. So far I'm not clear why reactos has taken 15 years to develop and yet still remain in alpha stage -- maybe due to the extra emphasis on wine-compatibility which need not necessarily be carried out by the third clone.
My view is that for best results both ntos and dos shell should equally and entirely be opensource based, and with wine-compatibility not enforced more than mere installation of the .exe and .msi files -- and maybe if possible even change the inbuilt gateway to viruses in "C:\windows\sc.exe" with either jws.jar or other opensource based modifications as long as the .exe/.msi installability remains unaffected.
Otherwise, one can still settle for a variation of .exe/.msi specific for the os like the way the .rpms are -- instead of the unproductive job of waiting for a very long time to achieve perfection of the catch-up process of reproducing even the proprietary bugs too.

5) Cygnome is the real gnome and has the potential to run on top of the kernel32.dll of all windows, reactos as well as the hypothetical greengnome os in the remote future.

Additional questions regarding Cygnome/Greengnome:

a) can cygnome (and greengnome) bring the zpanel/webmin/samba controlpanels too?

b) any possibility of also introducing the bulk-installer synaptic+apt-get for master-controlling either the msiexec or directly on installshield and regedit (which the msiexec script sequentially uses) in cygnome/greengnome for making the software-installation process appear like the ubuntu?

c) is there a possibility of cygnome (like greengnome) being developed from a desktop into a full-fledged os running from the nt kernel having no windows desktop?
can cygwin and greengnome be developed to have extensions into the openwatcom and freepascal frameworks of the freedos?

Hope to obtain positive result of test source code with modified oops running by testing on a fat32 drive containing both reactos and freedos installed which I think is to begin by converting a sample of delphi-code (for e.g. from pyscripter ide, greengnome app, etc) into cross-platform lazarus-code (and likewise for cygwin/openwatcom, etc), then try running on the reactos system as well as try extending it so as to contain a freedos instance via the existing cygwin/openwatcom and lazarus/freepascal frameworks.

Associated Factors for improving conversion of a comparatively more difficult task into a relatively quicker one:

1) freedos has to include other compilers such as gdc, python, ruby, gcj (openjdk), mcs (mono)/dotgnu, others, etc and develop its openwatcom framework into something like cygem (an opengem equivalent of cygwin), etc. Thus this will enable the advantages of extendabitity for gdc, python, ruby, others, cygem for applications which extend freedos instances as compared to others such as msdos, etc.
Ideally, the shell has to be an interface extendable from every compiler or frameworks, but a choice of one compiler each in most compatible form with opensource oops support has to be offered for applications with most reusable components (for extendability from these instead of direct interaction with kernel); and to also derive the more complex cygem subshell framework extending from the existing complete set of compilers which may or may not be from one single framework.
Maybe extending the cygem hopefully helps cygnome to "remove windows with cygnome(os)" type approach like that of the greengnome (and reactos).
Since cygnome also depends on gtk# (mono), the requirement of substitution of the msdos-instance's extensibility (via dotnetframework) with that of the freedos-instance's extensibility may arise. Solution is to port mono to freedos containing boo/python support, or (if not possible then) hope for other replacements -- dotgnu, gcj (openjdk, eclipse) or gdc.

2) use of django (python) and rails (ruby) [and even eclipse-glassfish or mono-moonlight] for web2 applications, including some components of controlpanels.
These are good alternatives to the php as a replacement for dotnet-silverlight based web2.

3) like c, pascal brings fast running apps but like c, pascal also requires huge lines of code -- implying bigger task so very long production cycle.
I think currently only c++ is used for a temporary code-volume reduction with a more productive option, but gnome's highest layers by definition cannot be c++ to avoid falling under the definition of xfce (but this does not mean complete non-usage of c++).
d-language of gdc compiler (of mingw (codeblocks)) is highly compatible with c, python and ruby since it is internally based on logic between these three -- but unfortunately it is much less used.
Moreover gdc balances the productivity of c# and java with the speed of c++, thereby making it ideal for making component layers lying between the low level freepascal and high level django/rails.
I think gdc can be used for most of the non-web2 components which do not need to directly extend a freedos instance, and maybe even those inclusive of them if freedos includes a gdc compiler in it. Also hope that gdc gets included in cygwin too.

i.e. in other words, to also look for the addition of as many gdc based component apps as possible to balance both speed and productivity to a good level but in an alternative way, i.e. with a set of lazarus (fpc), codeblocks (gdc), and django/rails -- held together by the gtk/qt/wx based oops.

Factors which might slowen up the pace of development:

1) there are not so many coders for pascal and d, and out of these very few are willing to adapt to change in oops such as delphi to lazarus, but fortunately CodeBlocks is fairly popular enough facility for gdc usage

2) unlike the greengnome, cygnome's comparatively long time for development is not much understood due to unknown problems. found everything ok except those related to combining all the parts together. but asking for cygnome as replacement to windows os itself would mean pending works more than greengnome.

3) freedos development has to improve more into an extensible shell with complete set of compiler support to kind of represent cygwin into it; although already has openwatcom and freepascal in it, it is yet to contribute much into applications and get preference over msdos.

4) New changes having capability of positively effecting developments:
(This is based on the understanding that cygwin itself as a text based win32 application (and not the true shell itself) and that its independence from native desktop requires a shell independence by extrapolating a symmetry and parity with a cygem analogue)
The introduction of ironpython as per the ironpython manual has finally brought in a superior replacement of powershell, and thus vsdotnet with powershell code (old technology) has a vsdotnet with ironpython code (new technology) which I think might already have been utilized somewhere since it has been stated to bring the popularity returning back to windows.
Moreover, since I think ironpython being less security prone it is good to see a possibility to replace powershell in every possible areas.
So, the same applies for mono+boo, dotgnu+python, jdk (netbeans)+jython, gcj (eclipse)+jython/python, gdc+python, etc
Here in this case, it is better for all utilities to use the open vm solutions rather than depend on a remotely linkable component from a proprietary framework.
Here like gcj, mono is compatible with native python in linux, and with boo in all os.
In windows, mono's compatibility with boo is beyond doubt.
If only native python is to be considered with 100% compatibility options in a restricted strip-down environment then a dotgnu would have been still better than mono, but instead of hoping for a non-existent option there are already gcj and gdc alternatives.
Thus, for expanding from a desktop alternative to a full fledged os alternative, all possible newer development helps in brining solutions earlier thought as impossible.
I think that once the desktop becomes stable release, in case of the phase2 the desktop2os development in more open environments such as reactos and freedos should give a truer picture than that in windows.
The picture likely to emerge is that either cygwin be developed as the only allowed (win32) shell application (others forbidden) having a cygnome, a shell-squared application of second order -- or the dos-shell itself is to be changed alongwith newer methods so as to reduce the shell-squared dependency of cygnome to maybe the python's functional logic way to reach the second order apps in a first order way (are we missing the fork???) or at least the cygem-gnome type approach.
However, due to the high risk factor involved in these experimentations, generally these are considered as closed -- unless the respective product vendors bring in new ways plus some miracles coming in for rescue.

5) The result of greengnome's removing and replacing windows from a desktop is usually expected to end up mostly in a false gnome os (reactos clone) with either same msdos or different freedos shell extensions.
If in case the new freedos is included then this gives an opportunity to bring more customizations at the shell level itself, leading to more finite pace of progress in terms of new approach in development.
It is also quite possible to converge the true cygnome-os with greengnome in the beginning and then fork out the expected kind of cygnome@shell-app@shell@kernel32.dll type solution extrapolated upto the cygnome@shell@kernel32.dll type benchmark which may or may not be attained at all -- and this way we can have the real gnome ntos too.
But we have to wait and see what way things go.

To take a break from description and stop with a humorous finish then:
If I were to name that work (if undertaken), then my choice would be:
X-CYCLED-Ntos, because:
CY = Cygwin
C=CodeBlocks (gdc)
L=Lazarus (fpc)
E=Emacs (freedos' fpc)
D=Django (python web2)
If Reactos, X=RE, or If Greengnome/Cygnome, X=G, or If (Cy)Kde, X=K, or if CyXfce, X=X itself, or If Windows, X= WHY (WI);

and of course R=Rails (ruby web2)

Reasons why NTOS' internal logic appears to be extremely confusing as compared to the Unix/FreeBSD/DarwinOS:

This is because there is one main difference between Windows and Reactos (ntos) on one hand and the Linux and Macosx on the other hand:
1) The dissimilarity is: In the Linux and Macosx the default shell are the bash/zsh/ksh and darwin-shell respectively, whereas for NTOS the default shell is either the Windows (Explorer) Shell or ReactOS (ROSExplorer) Shell -- i.e. the basic building block is the graphical interface itself.
2) The similarity is: In the Linux and Macosx the default terminals as XTerminal and Apple-XTerminal respectively, whereas in the NTOS, the default terminal is the extended application interface known as msdos shell available not by virtue of inclusion of msdos but as extended libraries inbuilt during the package development from the source development framework itself. That way we may also consider a filemanager as a graphical extension to the shell (but not exactly), as much as the terminal is a text extension to. In case of the cygwin, both the bash-shell and xterminal are equally extensions of the gui-shell, but the cygnome/cygwin-kde/cygwin-xfce, are all second-order layers built on top of the cygwin's bash shell. The other terminals are putty, etc.
3) Unix, Freebsd and DarwinOS began as text mode based multiuser interface os and hence their development into Linux and Macosx required making oops into toolkits, and full-fledged-interfaces; whereas Dos was a text mode single user interface which cannot be further developed into NTOS in a similar logical lines. NTOS rather is centered on the basic unit which is multiuser interface analogous from the Unix/Freebsd/DarwinOS, but done by a different way using a graphical shell unit powered with a text based extended interface with rights ranging from msdos to powershell to even more into the more recent dotnet knowhows. Whatever may be the difference, the basic similarity of being influenced with Freebsd's multiuser solutions approach remains as much for NTOS as DarwinOS, but it began as an applied logic with gui-shell+dos-terminal (applied from its development framework itself) without forking from Freebsd and the avoiding of any visibly looking similarities meant a huge difference of avoiding both apple's copyrights and others. On the other hand, the DarwinOS began as a pascal equivalent of FreeBSD plus several additional modifications which then steadily changed and became robust into the Macosx, whereas Unix evolved from FreeBSD emphasizing on more facilities for support for developing frameworks of all the programming languages (which later added very good security features for the Linux we know today).
4) I think the msdos-extensions can be replaced with freedos-extensions from openwatcom (gnu's gcc and g++) and from freepascal (fpc), using the emacs ide (or cream powered with gvim), or a combination of C-Ide (or CodeGears-Ide) and Lazarus-Ide; or maybe alternatively an entirely Eclipse based solutions.
5) Also, even the basic shell which is graphical can be replaced with various alternate shells plus alternate filemanagers, such as SharpEnviro+UltraExplorer, EmergeDesktop+DoubleCommander, Bblean/XobLite+muCommander/FreeCommander, etc. But once again except for the last two which are based on BlackBox shells, the first two depends on the msforms native graphical interface of the NTOS Shell.
6) The other main desktop-shell+filemanager having the opensource based graphical interface is the GreenGnome.
It is thus possible to think of an NTOS architecture of kernel32.dll tied to a GreenGnome desktopshell (plus GreenGnome filemanager) and a freedos extension terminal on top of the GreenGnome shell itself.
This is possible from Emacs running on either the gnu mode (openwatcom) or pascal mode (freepascal), since the freedos project also includes an inbuilt openwatcom (gcc and g++) and freepascal (fpc) compilers in it. Other IDEs are Cream powered with GVim, C-Ide (or CodeGears-Ide) in conjunction with Lazarus-Ide, etc.
Hopefully by virtue of containing the gcc, g++ and fpc the freedos project also adds up support for extendability via the mingw and cygwin frameworks too, so that in principle, one can also logically hope for the NTOS+kernel32.dll+others with other options such as wingnome+freedos (wingnome-ntos), cygnome+freedos (cygnome-ntos), etc. The last of these (i.e. all xcygwin based shells) represents a second-order derivative-layer of the original-shell, whose speed-enhancement-solution of lowering down back from higher layer status to the true-shell status might appear to be a quantum-mechanics type puzzle at the pre-flow-chart-level itself, and maybe the functionally-typed programming languages such as ocaml/f#/python, etc might probably be useful.
7) Recently, it has been found that the powershell (not the desktopshell+filemanager) can be replaced with IronPython, Boo, Python, Jython, etc.
8) Likewise, the dotnet can be replaced with java, mono, eclipse, parrot, aptana, gnu-emacs and cream+gvim (gnu based equivalent solutions), the ASP.NET/Silverlight can be replaced with EJB/Glassfish, Moonlight, PHP, Javascript, Django, Rails, Catalyst, Turbogears, Webkit, Ramaze, Maypole, etc.
This way the entire NTOS can be rewritten into an even more 100% pure opensource based implementation without the necessity of requiring to be bound to wine.

But I wonder!!! why you require windows? As always it sucks. Why all these are used in the native OS for which they are developed? After switching to linux I really hate using a windows system.

There is at least one area where the NTOS and Macosx are ahead of Linux such as -- the ability to recover its software-installer from electric powercuts if happened in the middle of a software installation.

Although we can recover using Linux it requires some manual command executions, and we have to wait for few more developments in the future for autorecovery so that these left out gaps are narrowed down to nil, which the windows and macosx are ahead.
Since both windows and macosx are equals in this respect, this difference in not due to registry-write installer system vs packet installer system -- but due to some more developments expected from the Linux front in the future.
Although I have in fact managed to successfully recover from such powercuts in all -- opensuse/mandriva/pclinuxos (easiest), ubuntu/linuxmint (also fairly easy enough), sabayon/gentoo (toughest), and others to name a few -- but this is an insignificant point offset due to much more number of other advantages and thus Linux is still my favorite -- but for a layman who do not appreciate knowing the commands for recovery they end up in returning back to windows.

Of course, the recent introduction of one-by-one-step-installer-systems such as ubuntu-software-installer (with some resemblance to the apple-software-installer) instead of a bulk-installer-system such as synaptic+apt-get is a huge boost for the Linux development. Even reactos' inclusion of ros-software-center catering for .exe based opensource software repository is very easily more impressive than at least the windowsxp, if not the windows7.

So, I think it is only a question of time to bridge the gap into that aspect plus others, but then the phenomenon of the most well used and familiar os product remaining the least understood of all baffles me the most.

Well, there is no doubt that Linux is an excellent OS but right now the point is to have identical DesktopShell+FileManager as cross-platform into all OS with improvised speed. If possible, in the future we can hope to see more of them with their own independent internal libraries for drivers, kernel, etc -- the kde for reactos project is the first such approach of path to independence after its success in windows (kde for windows), macosx (kde for macosx) and opendarwin. Similarly, we have cygnome for windows, gnome for opendarwin/macosx, etc which are not fully matured as those in Linux and OpenSolaris; so is the Xfce. In few years they all may develop that way.

This is to understand the method of transforming an OpenSource based DesktopShells and FileManagers from a full Windows dependency to a comparatively independent status with its own distro type approach with even less dependency to windows based libraries than the reactos.

[Note: These are significant as now-a-days there are viruses which infect the explorer.exe itself, and which we need as many alternatives as possible, preferrably built from opensource toolkits -- but they are anyway still only a temporary solution to the problem, since the viruses are known to attack the drivers, kernels and even hardwares. So ultimately each and every bits and pieces infected or infectable with viruses should have an opensource equivalent replacement, preferrably from gtk/qt/wx type widgets instead of the same familiar msforms (mfc)/bean-swing (jfc), etc. Not to forget that with the COM and Corba technologies operating via the sc.exe (via svchost), the technological attack on the user by invasion phenomenon is always at an advantage, and since we don't know the exact nature of its internal bugs, the sc.exe and even the process.exe needs to have other opensource based equivalents such as jws.jar (for sc.exe), etc.]

Unfortunately, currently none other than reactos has ever achieved this feat, which during 2009 looked like greengnome would also follow but didn't -- the reason probably is that the wrapper for gtk toolkit for pascal exists for gtk1 (gtkforpascal/gtkforlazarus) but not available and pending for gtk2 (gtk2forpascal/gtk2forlazarus) -- and gtk2 is very easily better than gtk1 both in terms of clarity as well as speed. These plus other factors unfortunately means that as on now we won't have others for quite a while.
The Other shells are unfortunately contended with the shell status -- which are only a short term solution.

The main thing is that although windows has the largest number of users, its exact internal mechanism corresponding to its relation with msdos are much less understood than the Linux and Macosx among their respective users.

No technology has ever been known to survive that way as 'so familiar and virtually unchanged and yet least understood' for so long.
Technology with changes both from different platform as well as the current platform is appreciated, and thus I would hope to see both Ubuntu with more auto-recovery from power-cuts, as well as a new ntos bearing more resemblance to linux even for synaptic+apt-get as a master-control-web2-layer on top of msiexec (/installshield+regedit) for running .exe/.msi files (instead of on the rpm/dpkg installers for running .rpm/.deb files), use of gnome shell with freedos extension, etc.

In this way, by porting of a bulk-installer such as synaptic+apt-get into a cross-platform tool (like the desktopshells and filemanagers) into both registry-write and packet installer system niches, its can be understood better and eventually addressable into more possible scope for future developments. This may be for both ways and maybe beneficial for aspects related to powercut recoverability for both installation systems. Or otherwise at least it would mean a more understanding for standardizing into fully cross-platform tools into both ubuntu and gnome-ntos for the future.

The inclusion of a posix subsystem in case of windows7 suggests a subsystem emulating the cygwin-framework itself for gccntos (ReactOS)/fpntos (based on either the gcc or an fpc-rewrite or a gpc within cygwin itself) would be a way out for improving the speed and performance of xcygwin (cygnome, kde-cygwin, cygwin-xfce) based applications after code modification (for the new framework) and rebuilding the packages, etc.
i.e. if the CodeBlocks-IDE/C-IDE (/Lazarus IDE/Geany) compiler path and environment settings are changed from cygwin (gcc/gpc) to those of the new emulating posix subsystem framework (gcc/fpc/gpc), and the xcygwin-application source code is modified accordingly, the IDE were used to recompile/rebuild then the newly built application should be faster and more efficient.
If this becomes possible, then in that case we can have the real gnome fast enough to replace their look-alikes; alternatively the gnu-pascal (gpc) would be useful by virtue of being available both for cygwin and mingw frameworks, and thus fpc/gpc (/mingw) based applications such as greengnome (/reactos-related-applications) can be ported initially into the cygwin (/mingw) (with code-changes), and then later into the posix-subsystem-framework (as gpc/fpc/gcc) and rebuilt into a gpc(/fpc)-real-nt-gnome type shell (after even more code-changes).