Features for a future Night

[Mercury Thirteen]

So, I've been thinking... What is the long-term goal of this project?

Granted, we began in a very "because we can" mindset, but in this era, that's not necessarily enough to make this project sufficiently different from all the others out there. After all, do we really need a second DOS? Or a hybrid Linux? Being the first fully 32-bit DOS to employ preemptive multitasking is already quite a distinction, but we shouldn't rest there.

I've been trying to think up something better. Something which could significantly alter the common perception of computers today.

Merely cloning common computing elements is a good start for any project, but we can't let the mundane desktop metaphor constrain us if innovation otherwise dictates.

That all being said, I believe it's worth fielding ideas on how we can improve the traditional desktop experience. I've listed a few improvements below, but I'm looking forward to any ideas you all may have!



-A "stacked" clipboard with animated screen popup when an item is added to or removed from the clipboard stack. This will more accurately convey the function of the clipboard to beginners.

-The ability to run binaries from multiple competing OS similar to the "personalities" feature from IBM's experimental Workplace OS. This would see the APIs of the implemented OS remade as driver modules under Night. This would allow the running of Linux, Windows, and DOS executables concurrently.

-A "document-centric" environment comprised of small editing components similar to Apple's ill-fated OpenDoc technology allowing users to focus more on their documents rather than the applications which make them.

-An expandable filesystem which will allow files to have an unlimited number of extra data tags appended to them to give the FS a more database-oriented feel and assist in searching. if this is done, perhaps the implementation of folders at the FS level can be done away with as well, instead giving the files a tag indicating which "folder" to which they belong.

So... what do you guys think? What features are on your wish list?

[Catharinus van der werf]

Thanks Mercury for your thoughts about  a future DOS.

I have a few wishes for a future DOS as well:

First I would like to see a USB-supported DOS. I guess you guys forgot that in the milestones-list.

Second, I would like to see a DOS that can automatically determine the need for a certain kind of memory. At this moment one needs to determine per used program what is the most optimal kind of memory. That should and I hope can be automatised, so that we don't need to type lh xxx. 

Third, I would like to see a DOS that can read NTFS-formatted harddrives.

Best regards

Catharinus

[Maarten Vermeulen]

Greetings and salutations! We come in peace. Anyway, I have some questions and comments.

First off, which Win executables do you want to support? There are apparently a lot of different kinds like Win 3.x and JIT.

Second, although NTFS would be pretty nice to have it's unfortunately very difficult to implement as it's complicated and hasn't got a whole lot of documentation (as far as I know).

Also the FS which supports unlimited data tags and tagging the folder with the file sounds good.

And the detecting of the kind of memory an app needs, shouldn't be that difficult(?) but some programs need a specific place in memory which we should figure out.

[Mercury Thirteen]

On Monday, March 12, 2018 at 7:22:45 AM UTC-4, Catharinus van der werf wrote:

Thanks Mercury for your thoughts about  a future DOS.

I have a few wishes for a future DOS as well:

First I would like to see a USB-supported DOS. I guess you guys forgot that in the milestones-list.

USB support will definitely be a goal! I guess it's not explicitly stated on the milestones list, but I had always considered it a part of the driver implementation line item. We will have to develop a USB driver which can abstract and enumerate drives plugged into USB ports to DOS apps.

 

Second, I would like to see a DOS that can automatically determine the need for a certain kind of memory. At this moment one needs to determine per used program what is the most optimal kind of memory. That should and I hope can be automatised, so that we don't need to type lh xxx. 

You mean EMS/XMS, etc.? Hopefully we'll be able to make that less of an issue by having each application in its own workspace.

 

Third, I would like to see a DOS that can read NTFS-formatted harddrives.

Another good idea! However with the lack of documentation on the format, we may only have a read-only driver for awhile.

 

Best regards

Catharinus

Thank you, and good suggestions! 

[Mercury Thirteen]

On Monday, March 12, 2018 at 7:59:22 AM UTC-4, Maarten Vermeulen wrote:

Greetings and salutations! We come in peace. Anyway, I have some questions and comments.

Alright, just as long as there are no abductions! lol

 

First off, which Win executables do you want to support? There are apparently a lot of different kinds like Win 3.x and JIT.

Just basic Win PE EXEs. No GUI stuff or Java (at least yet).

 

Second, although NTFS would be pretty nice to have it's unfortunately very difficult to implement as it's complicated and hasn't got a whole lot of documentation (as far as I know).

Agreed. Maybe just RO to begin with.

 

Also the FS which supports unlimited data tags and tagging the folder with the file sounds good.

The only downside to doing this is that the OS would have to scan a list of every single file on the harddrive to see which ones have a tag which matches the "folder" in which it's supposed to reside. On older systems this would not be feasible but newer ones shouldn't have much of a problem. Then again, older systems can simply use FAT.

[Mercury Thirteen]

On Monday, March 12, 2018, Chelson Aitcheson wrote:

#1 Use of the mouse in prompt to open files or perform tasks for example for he below tasks

Agreed, we will definitely be using the WIMP method.

 #2 ie Click on readme.txt and it opens or asks you which program you would like to open this with?

This feature would need to have some kind of file format index to recognize edit.com for example as a word or text editor

Basically a Default Programs-style list? I think DOS had a program (called... FASTOPEN maybe?) that provided this feature as well. Yep, pretty much a necessity in any modern OS.

 

#3 You could also employ a multi prompt cli desktop so you can run or be working on multiprompts.

Yes! I think this would tie in well with the "personalities" feature I mentioned above. Imagine being able to run cmd and bash side-by-side under the same OS!

#4 More color to the file extensions just to differentiate between execute files and other file types such as media, system etc..

That would be a nice thing to have in whatever default CLI we eventually adopt. 

#5 Multi driver support.

Now at this stage doscore uses a very primitive batch file and large pci I'd repository to determine what devices your PC might have. The only problem is lack of drivers. So porting of Linux driver's maybe could be cool?

I'm going to roll a set of default drivers to try to minimize dependence on tech from other platforms, using DOS or Linux ports only when necessary. Linux already does this, and it should serve us fairly well here.

 

#6 Networking: Smb, ftp server are two features I am currently working on in Aura gui . Smb at the dos level isn't all that hard and I even have a tsr ftp server that runs pretty good 

And this is just a few ideas while I had my morning coffee lol

 Yes, networking and interoperability will be paramount. We don't need any barriers to Night powering a PC in a modern setting. My vision for the kernel is to not be something users put on that old PC in the corner to run novelty DOS software. Eventually I want it to be a fully functional OS in its own right.

[Mercury Thirteen]

On 03/14/2018 07:08 PM, Chelson Aitcheson wrote:

Exactly, don't get me wrong I love the freedos community and I've had conversations about the roadmap of freedos with Jim I'm regards to bringing Aura gui closer to tying into the os apposed to just running on top of it and they are basically stuck on the idea that if it doesn't work on an xt based computer then we don't support any of my development.

I noticed. The way I see it is it's their project, so they can run it however they like. I, however, see no benefit in keeping it stuck in the 20th century. Yes, maintain a full compatibility mode or version for the purists, but at least allow some modernization to take place to bring it up to current standards. "Well if you want that, just use Linux." isn't an argument IMO; I do use Linux and I can still see where a modern DOS would fill a unique niche market. A huge one? Of course not. But it's there, and it would be nice to see what DOS could be had Microsoft not ditched it entirely.

 

Night dos can be that bridge that expands the open source dos realm. I spend my time developing software for clients and that's why I got into developing Aura gui and doscore years ago because I wanted to contribute something to the community that works on modern computers but still has a taste of the old world so both user of old and new era can learn or play or even use it as a tool.

 

Exactly, there's too much potential in the OS to just retire it. It's great for bare-bones systems or for those who wish to learn it. It's small, fast, and powerful; things which could not (easily) be said about any other OS. I see no reason why it shouldn't have a full GUI (personally, I'd love to see something that looks like Linux Mint's Cinnamon) and networking, USB, printing... the whole shebang.

I too see this as being more than a "me too" clone product.

 

Agreed. I suppose that, in a way, it's a good thing that FreeDOS isn't all too interested in Night. Not being painted into the "It has to still be DOS!!" corner liberates us enough to evolve the project further and take it in our own direction.

If we need some kind of funding or something done let me.know

 

Funding would be great, but unless it's a huge sum, it won't be enough to make me quit my day job and develop Night full time lol And don't get me wrong when I say that; I sincerely appreciate the offer!

I am currently working on the next milestone of aura m5, this is a big one. Full sdk and tcp applications.

 

Nice, it will be interesting to see what you produce! Are you building TCP support yourself or using an existing package, like mTCP?

[Mercury Thirteen]

On 03/18/2018 07:27 AM, Chelson Aitcheson wrote:

Hey there chelson from doscore here, me.and a couple of guys are getting ready to build our next release as we have been quiet but now have some more time. I thought your message for the future was interesting and we had some ideas of our own for freedos and doscore and thought your project eventually would supercede freedos and we wanted to share our vision of a "doslife" future. Bring night and freedos into the online age. Not just gui's and web browser. We are talking a full blown service. We haven't named it yet and it's still in it's infancy but I believe that it could bring dos hobbyists, nerds and something we've always wanted and that is a dos based service network for interactive dos. Sounds crazy or even a little silly but why not? I'm not talking about every old game being online (some) but I'm thinking of new games, software etc that has the online service platform wired to it . This would be a guy and prompt/dos app service. 
Have a read And let me.know what you think.
Thanks.

Overall, very good!

The one point where I think we differ in opinion is charging for some apps on the store service. Not to say it's not worth trying, but I don't see users paying for applications on our DOS platform when there are ones available on Linux for free, most of which are very good quality and highly functional due to there being literally thousands of developers involved with the platform. I think by leveraging our free and open source nature we can eventually attract enough of a user base that we can make some applications available for a fee, but in the beginning we would do well to focus on adding unique features and attracting developers so that we can get to that point.

So I guess in the long run, maybe we don't differ in opinion that much. It's just that I'd say it's too early to focus on the revenue-generating aspect of this at this stage of the game. :)

[Mercury Thirteen]

Another area of future development is the GUI which will run atop of Night. While I'm not a big fan of the modern "dock" style interface of Mac OS X, I think their older Copland / Rhapsody look was very nice indeed. Something like this from Gnome is also nice so far as the design of the Windows (the bar at the bottom, not so much). As I've mentioned before, Linux Mint Cinnamon also has a beautiful interface.

I think it would be good for us to create a sample app to be run under DOS so that we can evolve the GUI concurrently while the kernel is being developed. Chelson, you have experience in UI design from the Doscore / Aura projects; maybe you'd like to head up this venture? All it would need to be is a blank background with a single window with buttons and drop-downs allowing one to play with the UI to see how it would operate. Maybe we could even make this in such a way that it could handle the drawing for a variety of interfaces and switch between the themes at will as in any modern OS or maybe have a separate application for each version of the GUI. Whatever we do, we can't lock ourselves into one single GUI.

Perhaps any funding paths we take would be better focused into hiring external artists to create an icon set for us, if we can't make up something compelling ourselves.

Let me know what you guys think!

Oh, and if you want more yummy GUI samples of the above mentioned operating systems, check out GUIdeBookGallery.org.

[Maarten Vermeulen]

Few things, hope my criticism isn't getting annoying.

Remember a year or two back when you changed Night DOS Kernel to just Night Kernel? Because you didn't want Night to be associated with 'creaky old DOS', yet we're calling Night a DOS in this entire thread. So...
Next a few things about the GUI. First, when we ship a GUI with Night can we still call it a 32-bit DOS? I mean yeah sure if we don't enable it by default...
And second, I don't have any experience with making GUIs but I don't think we should make a GUI in all Assembly (because it's a lot of work).

I think, and I just want you to know, that if we want to improve on the original desktop experience or want to alter perceptions about it (in the way we're brainstorming right now) we do lose the abillity to deliver on the original missions [1]. I think it's a great road to take, far more exciting than the original one and certainly more attractive for new people.
Although we are using an early '90s type design for GUIs I do think this. I don't think we're able to do this and deliver on the old missions and if we are, we shouldn't... Unless you want two versions, but that wouldn't be practical with maintaining such a project with the small team we have.

It may be a stupid way to clarify, but what I'm trying to say is: You can't be a lunchroom and a clothes store at the same time. It's confusing for customers and is just a stupid brand idea, certainly if you're small.

[1] Original missions: 32-bit replacement for FreeDOS and all Assembly.

Yeah. That's it I guess...

[Antony]

All this in x86 assembly huh?

You might want to revisit the whole x86 vs C discussion. With all the features you want to add and things you want to do, C looks very appealing.

A lot of the performance gains you are looking for by using assembly can be achieved on a greater scale with the newer C compilers from GCC and or LLVM. Except for in the realm of 16-bit DOS, no one really uses the older C compilers. I think you'd be way further along in development if you were writing in C anyways.

I did think the original intent was to replace the FreeDOS kernel with a 32-bit version that would allow classic DOS applications to run, and bring new possibilities to DOS.

[Mercury Thirteen]

On Tuesday, March 20, 2018 at 6:39:43 PM UTC-4, Maarten Vermeulen wrote:

Few things, hope my criticism isn't getting annoying.

Never! Discussion is the whole purpose of this forum! 

Remember a year or two back when you changed Night DOS Kernel to just Night Kernel? Because you didn't want Night to be associated with 'creaky old DOS', yet we're calling Night a DOS in this entire thread. So...

I do. (Now. lol) That's something about which I had totally forgotten! True, we don't want to be associated with strictly a DOS-type platform, but in all honesty we do have our roots in DOS... I guess that's the best way I can explain the semantics mix-up at this point lol

Next a few things about the GUI. First, when we ship a GUI with Night can we still call it a 32-bit DOS? I mean yeah sure if we don't enable it by default...

Whatever GUI(s) / Window Manager(s) we make for use with Night will be completely separate projects; the only shared territory between them will be that they're designed to work with Night, nothing more. We may end up making the WM(s) available in the Night package or in the Night package manager, but it will not be an actual part of night and will definitely not be installed by default.

And second, I don't have any experience with making GUIs but I don't think we should make a GUI in all Assembly (because it's a lot of work).

I absolutely agree, only the kernel itself gets (or requires) that distinction. Any other programs, including windowing environments, will be made in whatever language the author chooses. I would suggest C.

 

I think, and I just want you to know, that if we want to improve on the original desktop experience or want to alter perceptions about it (in the way we're brainstorming right now) we do lose the abillity to deliver on the original missions [1]. I think it's a great road to take, far more exciting than the original one and certainly more attractive for new people.

Any improvements we make upon the traditional desktop tradition will be done in the window manager GUI, not in Night. Night's mission will continue to be replacing the traditional FreeDOS kernel. Any other awesomeness we make will run atop Night, not be a part of it.

 

Although we are using an early '90s type design for GUIs I do think this. I don't think we're able to do this and deliver on the old missions and if we are, we shouldn't... Unless you want two versions, but that wouldn't be practical with maintaining such a project with the small team we have.

It may be a stupid way to clarify, but what I'm trying to say is: You can't be a lunchroom and a clothes store at the same time. It's confusing for customers and is just a stupid brand idea, certainly if you're small.

[1] Original missions: 32-bit replacement for FreeDOS and all Assembly.

Right, we shouldn't be making two flavors of Night and we shouldn't make Night stray from its original goal. But in the end, we shouldn't have to. We can develop various parts at the same time (kernel, file system, driver framework, GUI, etc.) and because they're all separate projects, they shouldn't conflict or overlap one another.

 

Yeah. That's it I guess...

Good input, and thank you! Sorry if this reply is a bit un-structured or repetitive. I've had it open most of the day while working so I can type a little here and there as I have time, so it may not be as cohesive as usual lol 

[Mercury Thirteen]

On Tuesday, March 20, 2018 at 10:16:36 PM UTC-4, Antony wrote:

All this in x86 assembly huh?

Oh, heavens no! O.O

 

You might want to revisit the whole x86 vs C discussion. With all the features you want to add and things you want to do, C looks very appealing.

A lot of the performance gains you are looking for by using assembly can be achieved on a greater scale with the newer C compilers from GCC and or LLVM. Except for in the realm of 16-bit DOS, no one really uses the older C compilers. I think you'd be way further along in development if you were writing in C anyways.

Yes, everything outside the kernel will definitely be a higher-level language.

 

I did think the original intent was to replace the FreeDOS kernel with a 32-bit version that would allow classic DOS applications to run, and bring new possibilities to DOS.

It is, and will continue to be.

 

[Mercury Thirteen]

On 03/21/2018 12:34 AM, Chelson Aitcheson wrote:

sorry the CC was an accident lol

An accident? WHAT?? That's it. Get out. There will be no accidents here.

( Obviously jk :P )

 

its exactly why i do my own thing, of course i have used linux without shell and in bash for nix* but many of these features could benefit DOS..

Agreed, Linux pioneered a lot of nice innovations.

 

im not saying lets be a dos version of linux otherwise yeah it might aswell be linux but have these features without having to install different tsr applications and memory hogging 3rd party software it should OOBE.
the doslife idea is to bring life back into dos so people can develop it. yes you can set up your own packet drivers and stuff around with IDE and SDK manually but if you make it packaged and ready to go people will make applications for the platforms.
all you see now is tools for dos being developed, yes libraries in many languages are out dated and dead but either direction night dos goes isnt really up to me but dont limit it to just being a 32-bit dos that is exactly the same and the 16bit counterparts that has no "end user" improvements.

The main disadvantage of Linux is that it's underpinnings are a world apart from the Windows world. The average user doesn't want to compile their programs from source or have to run arcane commands from the terminal to get work done. Granted, there have been numerous strides in how Linux functions over the years to make it more user friendly, but at heart it's still a much more technical OS than Windows or Mac OS. The OS which brings its users the free and stable nature of Linux alongside an environment which is friendly, functional and easy to use will ultimately succeed. I believe that Night lays the foundation for this principle.

 

most people dont care about 642445-bit applications they care about will it work on my hardware and how far can i push this software?

Right, we have to have robust, capable software to create interest.

16 bit dos died because of its limitations so why would you create something designed to meet the same fate?
think of playstation 1 and playstation 2 backwards compatibility... PS2 was much better in every way and all the new games were the fad but if you wanted to YES you could always dip into the past and it was a good transitional machine. games for the ps2 were still developed till like 2012 or something which is crazy.
point is if your goal was set out to support 16 bit applications through some kind of layered emulation or native then do that but make enhancements for the end user.
where does the roadmap go after this for night dos?
at this point and time i feel like freedos is trying to add a bluetooth stereo to a steam powered tesla car.

FreeDOS, functional as it is, has stagnated as a platform. That's not necessarily a bad thing for the FreeDOS project; its mission was always to simply replace MS-DOS as it was. That being said, we have a much further-sighted goal: picking DOS back up, dusting it off, and making it something useful in a modern setting. Night is the basis of that mission.

As to the roadmap, I understand if there's some confusion for everyone on this due to my habit of rolling so many ideas over in my head that I forget which ones I have shared with you all and which I haven't. I guess I've never really laid out my current concepts for where things will go in the future, so this is a good a place as any to give the details.

Night is just one part of a larger plan to develop a fully functional stand-alone OS which will go above and beyond a classic DOS-style system to provide a thoroughly modern user experience.

In the past, I have made multiple attempts at creating an OS (a shell, technically) but no matter how far I got there was always some obstacle which made completing the project impractical. I tried everything from a simple BASIC-coded GUI, which taught me the basics of window management and mouse event processing, to a full 32-bit C program which ran under a DOS extender. I even briefly looked into emulation of the entire x86 opcode set using PowerBASIC code to perform multitasking in software! Through all these software tests, though, I was never able to multitask applications. The reasons why are obvious now, considering the technology I was using, but you have to consider I started this when I was in my mid teens and knew nothing about OS programming at the time. I did know, however, that I wanted my shell to be able to run existing programs, but also have room to grow and make custom apps which would compliment the additional features provided by the shell, creating what appears to the user to be a single, cohesive OS. The numerous versions I created were all unfinished and essentially amounted to nothing more than tech demos, getting completed only as far as they needed to be to show me how they wouldn't satisfy my goal. Through this, I slowly realized that the limitations of a traditional DOS-style kernel were too great, leading me to the revelation that any solid progress on this front would require delving much deeper into programming to create a custom kernel - Night.

Night is, on the surface, a 32-bit replacement for the FreeDOS kernel, but it will also provide the underpinnings of a larger system. With Night installed, a user will be able to run multiple DOS apps using whatever existing DOS shell they choose. Upon running a DOS app, the shell will send the load command to the kernel which would normally spawn the EXE then wait for it to finish executing before returning to the shell. Night will be different; the EXE to be run will be spawned as a separate process then control will immediately be returned to the shell in the background as if the program is already done executing. This will be transparent to the user, though, as the newly spawned program will take focus so that they may begin interacting with it. Or, they could Alt-Tab back to the shell and continue doing other operations including launching other programs.

By itself, Night alone will be sufficient if the user desires a simple multitasking DOS environment. If a GUI is desired, that can be done by replacing command.com with a graphical shell, just as one would do in any other DOS environment. This is where things get interesting.

There will be another project (yet to be formally launched) to create a modern windowing environment to run under Night which will provide desktop and file manager services. I haven't fleshed out all the technical details of how this would mesh with the kernel, but it should be fairly universal since it's merely another DOS application, albeit a Night-aware one. This opens the door to an a eventual selection of desktop managers from which the user could choose, each with its own look and feel. Aura could be one while another would mimic Linux Mint Cinnamon (can you tell how much I liked their interface?? lol) and yet another could look more retro, like Mac OS 9, etc.

Hopefully this clears up where my mind is going with this project, and help to keep us all on the same page.

[Mercury Thirteen]

On 03/23/2018 05:05 AM, Chelson Aitcheson wrote:

I think you should do a night gui, base it on what ever your heart desires and I will make Aura and doslife work on night and other dos systems.

Sounds good to me.

 

I would like to know how the driver management for like tsr's and extended memory drivers will work.

Since each DOS app will basically be running in its own environment, any TSR will have to be loaded into the memory space of every traditional DOS process which expects it to be there. A TSR will not be able to be loaded just once and then be available for every process.

 

Me and the doscore crew we're making jokes about having sounds in the command prompt Bing! Lol.

I'm surprised Microsoft never thought of that lol

 

If there is any information about development you can give me I would like to make drivers and probably some tcp stuff.

Generic drivers will be built into the kernel to support most devices and functions at a basic level. The kernel will scan the PCI bus and use the values returned to activate its own internal drivers where appropriate unless an external driver is launched to will supersede it. I'm starting on the disk controller driver as soon as I get the PCI issue fixed, but we will also need packet drivers, sound drivers and a networking stack supporting TCP and UDP.

 

I can't promise everything I make will be open source but I will contribute what I can :)

Thanks, we can use all the contributions we can get! lol

[Mercury Thirteen]

In my research, I found an interesting article on database file systems. Although it covers many of the bases of the topic, it (to my surprise) doesn't mention making file paths part of the metadata as well. Definitely worth a read, though. I think this is into what FAT64 will morph.

[Maarten Vermeulen]

It may not be the most elegant way of doing this, but using the root FS design and making the metadata show up as folders. You can add a file to multiple folders this way without the file size problem (as has also been stated by the article). Also, you can do stuff like calling a data tag 'folder.[name]' or 'folder=[name]' which would be the folder and then you have the option to add other metadata as well like 'mp3'.

I don't know, I haven't got any experience with any of this. But I hope this is possible.

[Mercury Thirteen]

On Sunday, April 1, 2018 at 2:38:50 PM UTC-4, Maarten Vermeulen wrote:

It may not be the most elegant way of doing this, but using the root FS design and making the metadata show up as folders. You can add a file to multiple folders this way without the file size problem (as has also been stated by the article). Also, you can do stuff like calling a data tag 'folder.[name]' or 'folder=[name]' which would be the folder and then you have the option to add other metadata as well like 'mp3'.

I don't know, I haven't got any experience with any of this. But I hope this is possible.

Good idea! I think this may ease the transition for folks who are used to a traditional hierarchical file system.

Perhaps the file manager would be able to run in both modes - with files organized in folders (as in pretty much every other file system ever) and using the folder location tag to determine which files belong to which folders, and also (at the user's request) the multi-folder tag mode you described above.

Making the database FS convenient and as seamless as possible could make file storage much easier.