It seems the release of 0.2 generated a lot of interest. Most of the reactions are pretty predictable, either "Why???" or "Wow!!!" with the "Wow" ones being in the majority I think.
The website served 1.8 million requests the last 24 hours. At times it was overloaded, but it seems we have found a set of parameters which works pretty well now.
Gé van Geldorp.
On Mon, 2004-01-26 at 11:56, Ge van Geldorp wrote:
It seems the release of 0.2 generated a lot of interest. Most of the reactions are pretty predictable, either "Why???" or "Wow!!!" with the "Wow" ones being in the majority I think.
The website served 1.8 million requests the last 24 hours. At times it was overloaded, but it seems we have found a set of parameters which works pretty well now.
Cool stuff! We also hit 43 users on #reactos yesterday afternoon (according to Royce), which is a new record.
-Vizzini
From: Vizzini
Cool stuff! We also hit 43 users on #reactos yesterday afternoon (according to Royce), which is a new record.
Checkout the download statistics on http://sourceforge.net/project/stats/?group_id=6553 too....
The main reason for this, IMO, is because the GUI has been improved. First impressions count, and screenshots of console apps really don't excite that many people - regardless of if it's running a Windows-compatible kernel or not.
Several of my friends turned their nose up at ReactOS months ago because they just saw it as being basic and maybe even "DOS-like". But since they saw the 0.2 screenshots, they're impressed and have become interested in it.
There have been the occasional "why?" questions asked by people I've mentioned ReactOS to, but those people are the kind that pay thru the nose for Microsoft software and who praise and worship Mr. Gates... Or who eat, sleep and breathe Linux...
In any case, ReactOS being so popular just goes to show that all the work that has been put into it is worth it. True, the beginnings have been quite slow and in some cases unstable, but with every code commit ReactOS gets better.
Hopefully everything will continue to go smoothly and in the next few years we'll have a 1.0 release ;)
I'd like to contribute some code again sometime soon, so I might start working on some winmm related stuff later this evening.
-Andrew
----- Original Message ----- From: "Ge van Geldorp" ge@gse.nl To: ros-general@reactos.com Sent: Monday, January 26, 2004 5:56 PM Subject: [ros-general] Interest in ReactOS
It seems the release of 0.2 generated a lot of interest. Most of the reactions are pretty predictable, either "Why???" or "Wow!!!" with the "Wow" ones being in the majority I think.
The website served 1.8 million requests the last 24 hours. At times it was overloaded, but it seems we have found a set of parameters which works pretty well now.
Gé van Geldorp.
_______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
surely if we are aiming for 100% M$ NT compatibility, we have no choice but to go with what is already there. as far as programs are concerned, they should believe that they are running on an M$ os. loads of registry entries and .ini files refer to C:, D: etc.
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
surely if we are aiming for 100% M$ NT compatibility, we have no choice but to go with what is already there. as far as programs are concerned, they should believe that they are running on an M$ os. loads of registry entries and .ini files refer to C:, D: etc.
I could imagine using UNC paths like "\mybox\mnt\cdrom\setup.exe" anywhere as replacement for drive letters. Perhaps one has to remain a single, small C: partition for programs, which don't understand to handle this. But you could get rid of mounting any of your otherpartitions at a drive letter.
However drive letters are not bad always. They can be used as shortcuts to deeper nested directories. By the way: XP also goes somewhat into this direction. You can mount partitions at any (NTFS) directory you like.
Regards,
Martin
ros@xzite.fsnet.co.uk wrote:
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
surely if we are aiming for 100% M$ NT compatibility, we have no choice but to go with what is already there. as far as programs are concerned, they should believe that they are running on an M$ os. loads of registry entries and .ini files refer to C:, D: etc.
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
Did the person who disliked drive letters say what they would like to see?
TomLeeM
I read a couple of opinions which disliked drive letters. When time goes by, we shuld think of a nice alternative
Hmm I really don't understand people concerned with drive letters. Actually, one of the main reasons a lot of people dislike Linux and Unix is the lack of drive letters and their crappy, monolithic file system. So, long life to drive letters!
The one and only thing to improve is how the OS assigns the letters to the partitions (the DOS/Win9x way was quite horrible, in Win2k/XP somehow better).
But more important yet, is to let the USER to decide the drive and the name of ALL the root folders created during Setup: not only C:\Reactos, but also "Program Files" and "Documents and Settings".
Lorenzo
Yes, drive letters have advantage of simplicity (well, to me :) ) But user must define it by himself (in config file, registry, or somehow else, like C:=/dev/hda1 :) ).
Example of windows stupidity: My friend has a primary master disk with two partitions, which shows as C: and D:. He has windows at C: and some programs at D:. But when I bring my one-partition-disk to him, and connect it as secondary slave, its partions becomes D:, and my friend's old D: becomes E: !
What did Bill thought, while doing such idiotic drive letter asignment system?
I read a couple of opinions which disliked drive letters. When time goes by, we shuld think of a nice alternative
L> Hmm I really don't understand people concerned with drive letters. Actually, L> one of the main reasons a lot of people dislike Linux and Unix is the lack L> of drive letters and their crappy, monolithic file system. So, long life to L> drive letters!
L> The one and only thing to improve is how the OS assigns the letters to the L> partitions (the DOS/Win9x way was quite horrible, in Win2k/XP somehow L> better).
L> But more important yet, is to let the USER to decide the drive and the name L> of ALL the root folders created during Setup: not only C:\Reactos, but also L> "Program Files" and "Documents and Settings".
L> Lorenzo
L> _______________________________________________ L> ros-general mailing list L> ros-general@reactos.com L> http://reactos.com/mailman/listinfo/ros-general
Dear Ñåðãåé Îðëîâ,
My friend has a primary master disk with two partitions, which shows as C: and D:. He has windows at C: and some programs at D:. But when I bring my one-partition-disk to him, and connect it as secondary slave, its partions becomes D:, and my friend's old D: becomes E:
I think that in your friend's HD C: was a primary partition and D: was an extended partition, and in your HD there was a primary partition, so Windows has given to it the precedence over the extended one.
What did Bill thought, while doing such idiotic drive letter asignment system?
Hmm, I don't think that the poor algorithm behind this problem was implemented by Bill. It's a little too easy to say that each stupid bug is caused by Bill.
But user must define it by himself (in config file, registry, or somehow else, like C:=/dev/hda1 :) ).
Yes, I agree, but please not with that Linux+Pascal hybrid notation! :-)
Lorenzo
At 09.46 28/01/2004, you wrote:
What did Bill thought, while doing such idiotic drive letter asignment system?
actually, Windows 2000 persists mount points and drive letters correctly. How does it do that I'm not sure. It also detects and handles the removal of partitions, but not resizing or moving them
It's (of course) somewhere in the registry. I can't remember, now. But you gan gather this info from readmes of the ext2-IFS for NT/2000. It's essentially a asociation between Volume UIDs and Letters which become created as ??\X:
KJK::Hyperion schrieb:
At 09.46 28/01/2004, you wrote:
What did Bill thought, while doing such idiotic drive letter asignment system?
actually, Windows 2000 persists mount points and drive letters correctly. How does it do that I'm not sure. It also detects and handles the removal of partitions, but not resizing or moving them _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
On 30.01.2004 01:38:28 KJK::Hyperion wrote:
At 09.46 28/01/2004, you wrote:
What did Bill thought, while doing such idiotic drive letter asignment
system?
actually, Windows 2000 persists mount points and drive letters correctly. How does it do that I'm not sure. It also detects and handles the removal of partitions, but not resizing or moving them
You can find it here for XP:
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices: ??\Volume{b247edb5-3486-11d8-a3ad-806d6172696f} ??\Volume{b247edb7-3486-11d8-a3ad-806d6172696f} .. \DosDevices\C: \DosDevices\D: ..
NT4's windisk.exe stored its settings in the HKEY_LOCAL_MACHINE\SYSTEM\Disk\Information entry, but this seems no more to be used nowadays.
Regards,
Martin
Lorenzo wrote:
I read a couple of opinions which disliked drive letters. When time goes by, we shuld think of a nice alternative
Hmm I really don't understand people concerned with drive letters. Actually, one of the main reasons a lot of people dislike Linux and Unix is the lack of drive letters and their crappy, monolithic file system. So, long life to drive letters!
[...]
Lorenzo
In fact I'm someone who dislikes driveletters (please don't beat me ;-). I like the Unix-style filesystem. I also like the Unix paradigma that everything is treated like a file. By this you have a unique way to access files, devices and everything else.
The same is with mounting drives somewhere in the file-tree. I think this way of drive access is much more elegant than assigning a letter to each drive. Has anybody ever tried what happens whe trying to use 27 devices under Windows? Will it use two letters then? Or numbers?
I think drive letters are a relict from old DOS times. And now that anybody is used to it there's no need to replace it by a better solution (because people don't like to throw away what they understood once and what they got used to).
Greetings
Björn
Dear Björn Fischer,
In fact I'm someone who dislikes driveletters (please don't beat me ;-). I like the Unix-style filesystem. I also like the Unix paradigma that everything is treated like a file. By this you have a unique way to access files, devices and everything else.
:-) I will not beat you! It's not a good idea to start a war of religion for such a reason!
The same is with mounting drives somewhere in the file-tree. I think this way of drive access is much more elegant than assigning a letter to each drive. Has anybody ever tried what happens whe trying to use 27 devices under Windows? Will it use two letters then? Or numbers?
The problem is that there is some kind of esthetics problem: I find horrible the Unix file system and do you finds horrible the drive letters. But let me say that in a system with 27 devices the problem is the design of that system, not the lack of drive letters! Then, in my system I have 6 partitions but only 3 HD letters, because I mounted some of them as NTFS folders, but I've still a good rationale behind the 3 letters (C: is system/binaries/programs, D: is personal data and projects, E: is multimedia *big* files). The big monolithic Unix approach tends to be messy and confuse, and it's hard to find where a file is (and to understand where it should be...)
The good thing (for me :-) is that it would be a very poor decision to get rid of drive letters in ROS.
Lorenzo
The problem is that there is some kind of esthetics problem: I find horrible the Unix file system and do you finds horrible the drive letters. But let me
Make it configurable so everyone can get what he/she wants. The setup should ask which kind of file system should be set up:
a.) MS Windows compatible b.) Unix FSH compatible c.) any mounted file system root and system directory configurable by the user
Regards,
Martin
I still think we should use the Linux-style file system, BUT use drive letters as shortcuts.
Somehow...
----- Original Message ----- From: "Martin Fuchs" martin-fuchs@gmx.net To: ros-general@reactos.com Sent: Wednesday, January 28, 2004 9:36 AM Subject: [ros-general] Re: Interest in ReactOS
The problem is that there is some kind of esthetics problem: I find
horrible
the Unix file system and do you finds horrible the drive letters. But
let me
Make it configurable so everyone can get what he/she wants. The setup should ask which kind of file system should be set up:
a.) MS Windows compatible b.) Unix FSH compatible c.) any mounted file system root and system directory configurable by the
user
Regards,
Martin
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
Maybe I'm missing something obvious here, but on my Win2k system I can mount any partition I want on any (NTFS) directory, just like you can mount filesystems on directories in Unix. So just make your C: drive NTFS, mount the other partitions, and forget about the C: if you want Unix-style paths.
When we reach compatibility in this area, this will be possible for ReactOS too. On the other hand, because of that same compatibility, we will have to support drive letters too. I really don't see why we would have to make a choice in this matter.
Gé van Geldorp.
Maybe I'm missing something obvious here, but on my Win2k system I can mount any partition I want on any (NTFS) directory, just like you can mount filesystems on directories in Unix. So just make your C: drive NTFS, mount the other partitions, and forget about the C: if you want Unix-style paths.
When we reach compatibility in this area, this will be possible for ReactOS too. On the other hand, because of that same compatibility, we will have to support drive letters too. I really don't see why we would have to make a choice in this matter.
The choice in setup would configure how the partitions are mapped to drive letters / mounted at directories. This is really missing in MS Windows' setup procedure. You can only choose on which drive and directory you want to install the system files.
Regards,
Martin
I have an even better idea, why not just map drives as Standard Windows Volumes like every other windows system, add some support for mounting smb volumes, appletalk shares, ftp folders, iso images, and stop complaining, why mess up a good thing? While you are at it add a linux subsystem with all the libraries to run common applications with basilisk II support and make the whole thing every-system-compatible!!! That is what I would think to do. But that is only me!
At 11.27 28/01/2004, you wrote:
Maybe I'm missing something obvious here, but on my Win2k system I can mount any partition I want on any (NTFS) directory, just like you can mount filesystems on directories in Unix.
It's not the same. There are subtle but important differences, that rarely show through everyday use but make the difference in complex scenarios. This is because the underlying model for filesystems is different: VFS on UNIX, IFS on Windows, and VFS is by far the best of the two. If it wasn't for the whole driver compatibility thingy, I wouldn't even have bothered with IFS, and would have gone straight for VFS. Just about the only thing about IFS that doesn't completely suck is the cache manager - the rest is forgettable garbage, and Microsoft's licensing of the IFS SDK hasn't helped either
Lorenzo wrote:
I still think we should use the Linux-style file system, BUT use drive letters as shortcuts.
Could you explain why? It would just add complexity, IMHO.
Lorenzo
In a book about Win NT internals I read that it is solved like kind of what Andrew said. Win NT generally uses the physical structure (device\harddisk0\parition1). But Access to this structure is done by logical structures which point to the physical structure (c:\ => device\harddisk0\parition1).
But I must say even though I prefer the unix style, to me it seems not practical to use this for ROS. ROS is a Win32 binary compatible system so all applications that (hopefully) will run on it should believe to run on a Win32. The same users should. So if there would be a difference (perhaps possibility to switch to Unix mode) many apps won't get along with it and not run anymore. So there MUST be drive letters to keep compatibility.
Greetings
Björn
I still think we should use the Linux-style file system, BUT use drive letters as shortcuts.
Somehow...
We can store files compatibleto the Unix File System Hierarchie, but we will not be able to use paths like /dev/mouse or /usr/local/bin/gcc, because this is not WIN32 compatible. But we could use "\mybox\dev\mouse" and "\mybox\local\bin\gcc" instead. This UNC path names are supported by WIN32. We only have to map them to the correct files. There is no need to use SMB and share the "\mybox..." folders via the network. A little extension to directly map them to the WIN32 file system is enough.
Regards,
Martin
For such compleete different paradigmas the right solution is another sub system. Or personality, if you prefer.
PS. ever tried that:
subst +: c:\ +: dir
Martin Fuchs schrieb:
I still think we should use the Linux-style file system, BUT use drive letters as shortcuts.
Somehow...
We can store files compatibleto the Unix File System Hierarchie, but we will not be able to use paths like /dev/mouse or /usr/local/bin/gcc, because this is not WIN32 compatible. But we could use "\mybox\dev\mouse" and "\mybox\local\bin\gcc" instead. This UNC path names are supported by WIN32. We only have to map them to the correct files. There is no need to use SMB and share the "\mybox..." folders via the network. A little extension to directly map them to the WIN32 file system is enough.
Regards,
Martin
Hi Robert, for some reason all your messages are empty when viewed in the newsreader (Outlook Express), and I'm not the only having this problem. It could be caused by the security digital signature you add to the message. Could you try to post a message without the signature? Thank you!
Lorenzo
I've noticed this as well.
The message arrives as an attachment. Sure, you can read it, but it means for each message you have to double click the attachment and choose OPEN... A bit inconvenient, and worrying especially at a time when there are viruses/worms on the loose, spreading via email attachments.
Vizzini's emails used to arrive as an attachment with a signature file as well, but I think he fixed that?
----- Original Message ----- From: "Lorenzo" garbage@loz.it To: ros-general@reactos.com; rob@koepferl.de Sent: Wednesday, January 28, 2004 6:40 PM Subject: [ros-general] Message for Robert K.
Hi Robert, for some reason all your messages are empty when viewed in the newsreader (Outlook Express), and I'm not the only having this problem. It could be caused by the security digital signature you add to the message. Could you try to post a message without the signature? Thank you!
Lorenzo
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
I think I also did. It took time to figure out that it is the signature which causes that (in this list system)
Andrew "Silver Blade" Greenwood schrieb:
I've noticed this as well.
The message arrives as an attachment. Sure, you can read it, but it means for each message you have to double click the attachment and choose OPEN... A bit inconvenient, and worrying especially at a time when there are viruses/worms on the loose, spreading via email attachments.
Vizzini's emails used to arrive as an attachment with a signature file as well, but I think he fixed that?
----- Original Message ----- From: "Lorenzo" garbage@loz.it To: ros-general@reactos.com; rob@koepferl.de Sent: Wednesday, January 28, 2004 6:40 PM Subject: [ros-general] Message for Robert K.
Hi Robert, for some reason all your messages are empty when viewed in the newsreader (Outlook Express), and I'm not the only having this problem. It could be caused by the security digital signature you add to the message. Could you try to post a message without the signature? Thank you!
Lorenzo
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
One thing I've noticed is that every message I've received from any of the lists has an attachment. This started just a couple days ago. I am using Outlook 2002.
-----Original Message----- From: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] On Behalf Of Andrew "Silver Blade" Greenwood Sent: Wednesday, January 28, 2004 12:09 PM To: ros-general@reactos.com Subject: Re: [ros-general] Message for Robert K.
I've noticed this as well.
The message arrives as an attachment. Sure, you can read it, but it means for each message you have to double click the attachment and choose OPEN... A bit inconvenient, and worrying especially at a time when there are viruses/worms on the loose, spreading via email attachments.
Vizzini's emails used to arrive as an attachment with a signature file as well, but I think he fixed that?
----- Original Message ----- From: "Lorenzo" garbage@loz.it To: ros-general@reactos.com; rob@koepferl.de Sent: Wednesday, January 28, 2004 6:40 PM Subject: [ros-general] Message for Robert K.
Hi Robert, for some reason all your messages are empty when viewed in the newsreader (Outlook Express), and I'm not the only having this problem. It could be caused by the security digital
signature you add
to the message. Could you try to post a message without the
signature?
Thank you!
Lorenzo
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-%3E general
What i suggested was neither of these. I suggested a generalization from dirve letters to drive words. Everyone is still free to use one character dirve words/identifiers
Lorenzo schrieb:
Dear Björn Fischer,
In fact I'm someone who dislikes driveletters (please don't beat me ;-). I like the Unix-style filesystem. I also like the Unix paradigma that everything is treated like a file. By this you have a unique way to access files, devices and everything else.
:-) I will not beat you! It's not a good idea to start a war of religion for such a reason!
The same is with mounting drives somewhere in the file-tree. I think this way of drive access is much more elegant than assigning a letter to each drive. Has anybody ever tried what happens whe trying to use 27 devices under Windows? Will it use two letters then? Or numbers?
The problem is that there is some kind of esthetics problem: I find horrible the Unix file system and do you finds horrible the drive letters. But let me say that in a system with 27 devices the problem is the design of that system, not the lack of drive letters! Then, in my system I have 6 partitions but only 3 HD letters, because I mounted some of them as NTFS folders, but I've still a good rationale behind the 3 letters (C: is system/binaries/programs, D: is personal data and projects, E: is multimedia *big* files). The big monolithic Unix approach tends to be messy and confuse, and it's hard to find where a file is (and to understand where it should be...)
The good thing (for me :-) is that it would be a very poor decision to get rid of drive letters in ROS.
Lorenzo
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
On Wed, 28 Jan 2004, [ISO-8859-1] Björn Fischer wrote:
In fact I'm someone who dislikes driveletters (please don't beat me ;-). I like the Unix-style filesystem. I also like the Unix paradigma that everything is treated like a file. By this you have a unique way to access files, devices and everything else.
Actually, NT sort of has this. The executive treats everything as an object which is some structure that is of a certain class (again, an object) and has a set of methods. The objects are arranged in a tree and the tree is "owned" by the object manager.
Win32 drive letters are simply mounted objects in the tree under the branch of DosDevices that have their own parse methods.
So lets say you have X: as your drive letter, thats \DosDevices\X:\foo\bar to the object manager. The "\foo\bar" part is passed to X:'s parse method where it handles filename lookup and then returns a file object (from the I/O manager).
Removing drive letters all together would cause some serious problems for existing Win32 apps but I wonder how much trouble it would cause to create a symlink under \DosDevices to \DosDevices so you get a single "super drive" letter.
If you want to be really daring you could create a symlink under \DosDevices to the object tree root and then get access to everything via one interface. In fact, named Win32 objects like semaphores and mutexes are also there under \BaseNamedObjects, IIRC.
The same is with mounting drives somewhere in the file-tree. I think this way of drive access is much more elegant than assigning a letter to each drive. Has anybody ever tried what happens whe trying to use 27 devices under Windows? Will it use two letters then? Or numbers?
Actually, NTFS supports reparse points that do this. But its up to the filesystem since the parse method for X: ends up in the IFS code.
I think drive letters are a relict from old DOS times. And now that anybody is used to it there's no need to replace it by a better solution (because people don't like to throw away what they understood once and what they got used to).
Right, but changing the Win32 API is bound to break compatability; and thats an important goal of ReactOS. But thats okay, the architecture of NT allows for more than one subsystem. You could write a Native API program if you really wanted to (most of the Win32 facilities are there for you in "raw" form) or you could write your own OS API via a subsystem.
I guess it wouldn't be too hard for somebody to code up an alternative protected subssytem to give a much more object-oriented API than Win32. Programs that are not concerned with backwards compatability could use the new runtime environment.
I totally agree about things being more uniform. When they designed the Win32 API backwards compatability was an important goal -- I personally think the Presentation Manager API is much better than the windows one (it makes more sense rather than all the "non-client" special casing). But they chose that for backwards compatability.
Hell, there is still the Global and Local memory API's.
Personally I think we should leave the Win32 API in ReactOS as is for backwards compatability but we should encourage (eventually) the writing of another subsystem for a nice, object-oriented API. The two can co-exist quite easily.
In fact, a lean-and-mean subsystem would be just the thing for embedded applications that have no need for backwards compatability. And that could be a decent application of ReactOS on its own -- there is money to be made in the embedded world with GPL code. ;-) Well, I used to believe that anyhow.
L8r, Mark G.
Right, but changing the Win32 API is bound to break compatability; and thats an important goal of ReactOS. But thats okay, the architecture of NT allows for more than one subsystem. You could write a Native API program if you really wanted to (most of the Win32 facilities are there for you in "raw" form) or you could write your own OS API via a subsystem.
excuse me to correct: It's not an API or ABI change but a semantic change. Semantics of file naming. However it can be made either compatible or not.
Correct me: Does the win32 API has got a function to test file name semantics? UNC-names are widely understood. And since common dialogs, i think noone does real name checking.
I think your embedded -adapted api is a good idea. AFAIK M$ is working on s.t. like this removing a lot of deprecated calls, like apple did with carbon. But will MS break compatibility?
On Wed, 28 Jan 2004, Robert K. wrote:
Right, but changing the Win32 API is bound to break compatability; and thats an important goal of ReactOS. But thats okay, the architecture of NT allows for more than one subsystem. You could write a Native API program if you really wanted to (most of the Win32 facilities are there for you in "raw" form) or you could write your own OS API via a subsystem.
excuse me to correct: It's not an API or ABI change but a semantic change. Semantics of file naming. However it can be made either compatible or not.
Well, the semantic change will break a lot of programs that parse file names. There is lots of *shitty* code out there in the Win32 world.
Correct me: Does the win32 API has got a function to test file name semantics? UNC-names are widely understood. And since common dialogs, i think noone does real name checking.
I work on code that does this kind of crap daily (don't ask, I hate this job). But when the code I work on gets a UNC name, it uses the WNet API its self, when it sees anything else it expects a 1-character drive letter.
I didn't write this garbage and don't want to touch it any more than I have to, but there is *lots* of code out there that does similar things. It also seems to avoid common dialogs too for whatever reason. [*]
But the bottom line is that the semantics are part of the API. The best you could do is a UNC path like:
\myhost\root\blah\blah
And then *really* SMB serve that to yourself locally. It seems like a lot of effort for very little gains.
I think your embedded -adapted api is a good idea. AFAIK M$ is working on s.t. like this removing a lot of deprecated calls, like apple did with carbon. But will MS break compatibility?
Some of the compatability code in Windows is scary. They tend to detect what app is running and adjust for that in a lot of places (seriously).
ReactOS shouldn't be littered with that kind of garbage, but changing the semantics is going to break a lot of existing code.
[*] The code at my current place of employment was written back in the 3.1 days and not very well to begin with. Age hasn't been kind to it. I have zero intention of fixing it. I am just going to browse slashdot until I am canned.
On Wed, Jan 28, 2004 at 04:34:12PM +0100, Robert K. wrote:
I think your embedded -adapted api is a good idea. AFAIK M$ is working on s.t. like this removing a lot of deprecated calls, like apple did with carbon. But will MS break compatibility?
I don't think so, backwards compatibility has always been an important issue for windows. Win XP for instance still is compatible with win 1.0 :)
Mark
Personally I think we should leave the Win32 API in ReactOS as is for backwards compatability but we should encourage (eventually) the writing of another subsystem for a nice, object-oriented API. The two can co-exist quite easily.
I actually had a few ideas for this, related to the file system thread a while ago. One idea was to have object descriptors (classes) as a DLL of some form, and then have subclasses as actual files or objects.
So an MP3 file would be an object of type mp3file, which would be a subclass of audiofile, subclass of file, etc.
Bit difficult to explain especially as the design is still incomplete.
But in any case, I feel an object-oriented API would be nicer. This is however difficult as callbacks for C++ objects are a pain (you can't seem to pass a pointer to a member function to anything) without doing some sort of bodged workaround (usually involving lots of little macros...) You could, of course, have standard OnPaint() OnKeyDown() etc routines, or even have an event object which gets passed around. But this still has difficulties.
On Wed, 28 Jan 2004, Andrew "Silver Blade" Greenwood wrote:
So an MP3 file would be an object of type mp3file, which would be a subclass of audiofile, subclass of file, etc.
Yeah, that makes a lot of sense and its the kind of thing OS/2's Workplace Shell tried to bolt on using SOM. It was also part of Apple's Pink project (somewhere I still have a Taligent programming manual).
But in any case, I feel an object-oriented API would be nicer. This is however difficult as callbacks for C++ objects are a pain (you can't seem to
Probably a language-neutral API and then writing a C++ wrapper for the API is the best way to go.
pass a pointer to a member function to anything) without doing some sort of bodged workaround (usually involving lots of little macros...) You could, of course, have standard OnPaint() OnKeyDown() etc routines, or even have an event object which gets passed around. But this still has difficulties.
The event object is a good paradigm -- it makes distributed computing easier if a message in transit can also receive messages to its self (same with class objects).
Such a discussion is probably outside the scope of the reactos project though. They are providing a kernel that supports a particular API. An OO subsystem could probably be built running on a Microsoft Windows box and then ported over to ReactOS with almost minimal effort.
But that kind of stuff seems more like the realm of the application... my particular area of interest is embedded where filesystems are rare.
L8r, Mark G.
I like and dislike drive letters.
I dislike them because they aren't really necessary and you must have at least one if you have a hard drive (eg: drive C), which means even though I have a separate partition for my data, I can either have it as a separate drive D: (which I do), or mount it under the C: drive somewhere (which I don't want to do, because there's no point if I'm going to be using a drive letter anyway!)
However, I like them because they serve as a quick way to access your favourite folders. I use SUBST a lot for this purpose (usually have R: pointing to my ReactOS folder, and W: to a workspace folder containing junk needing sorting out!) So they save a lot of typing.
PS: Any chance you can set your mail client up to send the actual message in-line rather than having it as an attachment (at least, thats how OE sees it...)
----- Original Message ----- From: "robert K." rob@koepferl.de To: ros-general@reactos.com Sent: Monday, January 26, 2004 7:20 PM Subject: Re: [ros-general] Interest in ReactOS
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
I fallen in a deep coma where i did my diploma thesis. It's finished now. Jus at that time where heise.de anounced ROS.
KJK::Hyperion schrieb:
At 20.20 26/01/2004, you wrote:
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
hey Robert! where have you been for so long? _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
Offhand -> Floppy; -> Home/User Drive; -> System Disk; -> Data Disk; -> CD/DVD ROM/R/RW
What do people think?
On Tue, 27 Jan 2004 08:20, robert K. wrote:
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
I think, that drive letters must be bindings to something else (like in wine)
Tuesday, January 27, 2004, 11:14:02 AM, âû íàïèñàëè:
Offhand ->> Floppy; ->> Home/User Drive; ->> System Disk; ->> Data Disk; ->> CD/DVD ROM/R/RW
WP> What do people think?
WP> On Tue, 27 Jan 2004 08:20, robert K. wrote:
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
So do I.
I can think of a computed Superroot directory which contains all volume names as directorys and Drive letters are an optional thing which can be assigned to improove compatibility.
OR
Use the Volume names as Dirve Identifiers Myvolume:\readme.txt
orlov@avdis.ru schrieb:
I think, that drive letters must be bindings to something else (like in wine)
Tuesday, January 27, 2004, 11:14:02 AM, âû íàïèñàëè:
Offhand ->> Floppy; ->> Home/User Drive; ->> System Disk; ->> Data Disk; ->> CD/DVD ROM/R/RW
WP> What do people think?
WP> On Tue, 27 Jan 2004 08:20, robert K. wrote:
I read a couple of opinions which disliked drive letters.
When time goes by, we shuld think of a nice alternative
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
-----Oprindelig meddelelse----- Fra: ros-general-bounces@reactos.com [mailto:ros-general-bounces@reactos.com] På vegne af Robert K. Sendt: 27. januar 2004 11:19 Til: Ñåðãåé Îðëîâ; ros-general@reactos.com Emne: Re: [ros-general] Interest in ReactOS
So do I.
I can think of a computed Superroot directory which contains all volume names as directorys and Drive letters are an optional thing which can be assigned to improove compatibility.
Already present in Windows. The shell does this.
OR
Use the Volume names as Dirve Identifiers Myvolume:\readme.txt
Why have them at all then? The primary purpose of drive letters was/is to avoid typing long names.
Casper
Why have them at all then? The primary purpose of drive letters was/is to avoid typing long names.
No one hinders you to name volumes with 1c-names But this gibves you freedom. Dont care
Casper
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ? For ex. when ROS becomes stable enough i will surely pass to ROS instead of Linux (that i use now). Of course having a lot of GNU utils in ROS , GPL licence, and free Win32 implementation is a temptation for many developers and even GNU/Linux users. So isn't ROS going to unbalance the balance between GNU/Linux / BSD ..etc and MS Win ?
Pe data de Luni 26 Ianuarie 2004 19:56, Ge van Geldorp a scris:
It seems the release of 0.2 generated a lot of interest. Most of the reactions are pretty predictable, either "Why???" or "Wow!!!" with the "Wow" ones being in the majority I think.
The website served 1.8 million requests the last 24 hours. At times it was overloaded, but it seems we have found a set of parameters which works pretty well now.
Gé van Geldorp.
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
On Mon, Jan 26, 2004 at 09:25:05PM +0200, Ciobanu Alexander wrote:
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ? For ex. when ROS becomes stable enough i will surely pass to ROS instead of Linux (that i use now). Of course having a lot of GNU utils in ROS , GPL licence, and free Win32 implementation is a temptation for many developers and even GNU/Linux users. So isn't ROS going to unbalance the balance between GNU/Linux / BSD ..etc and MS Win ?
Well, maybe it will, but what's the problem with that?
Mark
Pe data de Luni 26 Ianuarie 2004 21:38, Mark IJbema a scris:
"Me" thinks it's a somehow interesting problem .... As GNU operating system is the main goal for KDE/Gnome - like projects, this would mean : 1. Porting to win32 and loosing popularity (ROS is somewow more integrated than GNU so i wouldn't like to use KDE for ex. if i'm a user, i would rather use explorer ... etc) 2. Continuing on GNU ,and loosing popularity (reasons said below) 3. Dismemberment (bad ideea :( )
Of course i would like to see for ex. Kopete (instant messenger) from KDE working on "my ROS box" :) but somehow without QT and KDE :)
On Mon, Jan 26, 2004 at 09:25:05PM +0200, Ciobanu Alexander wrote:
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ? For ex. when ROS becomes stable enough i will surely pass to ROS instead of Linux (that i use now). Of course having a lot of GNU utils in ROS , GPL licence, and free Win32 implementation is a temptation for many developers and even GNU/Linux users. So isn't ROS going to unbalance the balance between GNU/Linux / BSD ..etc and MS Win ?
Well, maybe it will, but what's the problem with that?
Mark _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
Just use Trillian instead of Kopete :)
----- Original Message ----- From: "Ciobanu Alexander" alex@prodidactica.md To: ros-general@reactos.com Sent: Monday, January 26, 2004 7:59 PM Subject: Re: [ros-general] Interest in ReactOS
Pe data de Luni 26 Ianuarie 2004 21:38, Mark IJbema a scris:
"Me" thinks it's a somehow interesting problem .... As GNU operating system is the main goal for KDE/Gnome - like projects, this would mean : 1. Porting to win32 and loosing popularity (ROS is somewow more integrated than GNU so i wouldn't like to use KDE for ex. if i'm a user, i would rather use explorer ... etc) 2. Continuing on GNU ,and loosing popularity (reasons said below) 3. Dismemberment (bad ideea :( )
Of course i would like to see for ex. Kopete (instant messenger) from KDE working on "my ROS box" :) but somehow without QT and KDE :)
On Mon, Jan 26, 2004 at 09:25:05PM +0200, Ciobanu Alexander wrote:
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ? For ex. when ROS becomes stable enough i will surely pass to ROS instead of Linux (that i use now). Of course having a lot of GNU utils in ROS , GPL licence, and free Win32 implementation is a
temptation
for many developers and even GNU/Linux users. So isn't ROS going to unbalance the balance between GNU/Linux / BSD ..etc and MS Win ?
Well, maybe it will, but what's the problem with that?
Mark _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
On Mon, Jan 26, 2004 at 09:59:54PM +0200, Ciobanu Alexander wrote:
Pe data de Luni 26 Ianuarie 2004 21:38, Mark IJbema a scris:
"Me" thinks it's a somehow interesting problem .... As GNU operating system is the main goal for KDE/Gnome - like projects, this would mean :
- Porting to win32 and loosing popularity (ROS is somewow more integrated
than GNU so i wouldn't like to use KDE for ex. if i'm a user, i would rather use explorer ... etc) 2. Continuing on GNU ,and loosing popularity (reasons said below) 3. Dismemberment (bad ideea :( )
Of course i would like to see for ex. Kopete (instant messenger) from KDE working on "my ROS box" :) but somehow without QT and KDE :)
Well, this would be the case if it would wipe linux+kde out of the market, which probably won't be the case. Each system has it's advantages and disadvantages. Sure ROS will take some market, but competition is healthy imho, also for OSS software. I really see no reason to worry. Look at FreeBSD/Linux for instance, they have coexisted for quite some time as well.
Mark
Mark IJbema wrote:
On Mon, Jan 26, 2004 at 09:25:05PM +0200, Ciobanu Alexander wrote:
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ? For ex. when ROS becomes stable enough i will surely pass to ROS instead of Linux (that i use now). Of course having a lot of GNU utils in ROS , GPL licence, and free Win32 implementation is a temptation for many developers and even GNU/Linux users. So isn't ROS going to unbalance the balance between GNU/Linux / BSD ..etc and MS Win ?
Well, maybe it will, but what's the problem with that?
Mark
Why should it? I think the term "free" is like the one in 'free speech', not 'free beer'. ROS will be free in that meaning. Why shouldn't the variety of OS's grow? I think the more free OS's there are, the better it is for the user because he is free in choosing the OS he likes.
Probably "militant" open source lovers will have problems with ROS because it is supposed to be compatible with a lot of "non-free" software. But I think it would be good for users.
Greetings
Björn
Björn Fischer wrote:
Mark IJbema wrote:
On Mon, Jan 26, 2004 at 09:25:05PM +0200, Ciobanu Alexander wrote:
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ? For ex. when ROS becomes stable enough i will surely pass to ROS instead of Linux (that i use now). Of course having a lot of GNU utils in ROS , GPL licence, and free Win32 implementation is a temptation for many developers and even GNU/Linux users. So isn't ROS going to unbalance the balance between GNU/Linux / BSD ..etc and MS Win ?
Well, maybe it will, but what's the problem with that?
Mark
Why should it? I think the term "free" is like the one in 'free speech', not 'free beer'. ROS will be free in that meaning. Why shouldn't the variety of OS's grow? I think the more free OS's there are, the better it is for the user because he is free in choosing the OS he likes.
Probably "militant" open source lovers will have problems with ROS because it is supposed to be compatible with a lot of "non-free" software. But I think it would be good for users.
Greetings
Björn _______________________________________________ ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
As ReactOS is a free version of WinNT, OSFree ( http://www.osfree.org ) is a free/clone of OS/2 Warp by IBM. A 'fyi' reply (I am interested in both).
http://www.freeos.com is a site for 'free operating systems.
TomLeeM
We know of it. Does your comment mean that you are now willing to implement osfree via a subsystem on ROS and thus help me?
If yes, I could partition the work amount and asingn functions. Otherwise I start the JFS-port again.
As ReactOS is a free version of WinNT, OSFree ( http://www.osfree.org ) is a free/clone of OS/2 Warp by IBM. A 'fyi' reply (I am interested in both).
http://www.freeos.com is a site for 'free operating systems.
TomLeeM
Robert K. wrote:
We know of it. Does your comment mean that you are now willing to implement osfree via a subsystem on ROS and thus help me?
If yes, I could partition the work amount and asingn functions. Otherwise I start the JFS-port again.
As ReactOS is a free version of WinNT, OSFree ( http://www.osfree.org ) is a free/clone of OS/2 Warp by IBM. A 'fyi' reply (I am interested in both).
http://www.freeos.com is a site for 'free operating systems.
TomLeeM
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
OSFree is still being worked on. I am not a programmer but will consider your idea. http://groups.yahoo.com/group/osfree I will forward your message to the above group to seek the opinion of those in it.
TomLeeM
I'm on both lists. And there's already st. around with yuri, if he has time over his diploma
Tom Lee Mullins schrieb:
Robert K. wrote:
We know of it. Does your comment mean that you are now willing to implement osfree via a subsystem on ROS and thus help me?
If yes, I could partition the work amount and asingn functions. Otherwise I start the JFS-port again.
As ReactOS is a free version of WinNT, OSFree ( http://www.osfree.org ) is a free/clone of OS/2 Warp by IBM. A 'fyi' reply (I am interested in both).
http://www.freeos.com is a site for 'free operating systems.
TomLeeM
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
OSFree is still being worked on. I am not a programmer but will consider your idea. http://groups.yahoo.com/group/osfree I will forward your message to the above group to seek the opinion of those in it.
TomLeeM
I was just wondering, don't you guys think ReactOS is a treat to GNU/Linux ?
yup! ain't it cool?
yea, we shuld think of applying at Microsoft or SCO
ros-general mailing list ros-general@reactos.com http://reactos.com/mailman/listinfo/ros-general
-
Andrew "Silver Blade" Greenwood -
Björn Fischer -
Brian Palmer -
Casper Hornstrup -
Ciobanu Alexander -
Ge van Geldorp -
john＠shepherdtrack.com -
KJK::Hyperion -
Lorenzo -
Mark Grosberg -
Mark IJbema -
Martin Fuchs -
orlov＠avdis.ru -
Rick Langschultz -
Robert K. -
robert K.
-
ros＠xzite.fsnet.co.uk -
Tom Lee Mullins -
Vizzini -
Wesley Parish -
Ñåðãåé Îðëîâ