Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Casper H. <ch...@us...> - 2002-05-31 12:55:15
|
fre, 2002-05-31 kl. 18:50 skrev Yuri Prokushev: > On Fri, 31 May 2002 07:28:16 +0200, Patrick Mauritz wrote: > > >On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: > >> OS/2 has its own graphics and windowing API: why should it use Win32? > >it should at least use win32 windows and messages - that way you can > >run win32 and os/2 stuff on one desktop. > >getting them on one desktop with two distinct "window lists" (or however they > >are stored internally) you'll have a big time trying to keep them all > >up-to-date... > Well. Question is _why_ should it use win32? _Why_ not win32k? Of couse, os2ss (and any other ss) can (and must) use common window manager and messages. But > why make it depended on win32? I don't like this aproach. I consider usage of win32k graphics is ok, but usage of win32 graphics and highlevel objects is bad. I don't like > to see win32-looks windows on my desktop. I prefer to see os2-style windows on my desktop. Maybe you don't like it because you still see user32.dll and gdi32.dll as Win32 components. Well that all changed when we decided to make them native. Even such a small change can make a big difference to how you percieve things. Now, these components have been adopted as _the_ standard user mode interface to the window manager and GDI and they are no more part of the Win32 subsystem than any other subsystem. They are subsystem support code. Using these DLLs in subsystems does not mean that the subsystems cannot have their own look and feel. It gives you the _option_ of not having to duplicate the user32.dll for each and every subsystem and you can then focus on getting your subsystem to do what it is supposed to do; run applications that expect certain APIs. You also have the option of reimplementing user32.dll if you feel strongly about your applications look and feel differently from others on the desktop. - Casper |
|
From: Yuri P. <pro...@fr...> - 2002-05-31 11:44:25
|
On Fri, 31 May 2002 11:36:50 +0100, Nick Date wrote: >> > OS/2 has its own graphics and windowing API: why should it use Win32? > >> it should at least use win32 windows and messages - that way you can >> run win32 and os/2 stuff on one desktop. >> getting them on one desktop with two distinct "window lists" (or however >they >> are stored internally) you'll have a big time trying to keep them all >> up-to-date... >I see where you're coming from here. I'm wondering how much of win32 it >would be feasable to strip from ReactOS if the user only wants to run OS/2 >apps (save some space on your 40 gig hard disk :-] ). Why I need storage space for unused things? > It seems to me that in >order to do this you'd have to go back to the kernel and write an OS/2 >GDI/GUI, but wouldn't this be a seperate project from OS/2 binary >compatibility? Who needs binary compatibility without APIs? GDI implemented by win32k. Isn't it? So all OS/2 GPI (=GDI) can be easely implemented like gdi32.dll (pmgpi in os2). Highlevel objects (user32.dll in win32) can be just copied (for common object like editfield). For other controls (like spinbuttons) code must be written from the scratch. So I don't see any reason for implement pmgpi via gdi32 instead of direct implementation via win32k. |
|
From: Nick D. <nic...@ya...> - 2002-05-31 10:37:20
|
Hi Patrick, ----- Original Message ----- From: "Patrick Mauritz" <ox...@st...> To: <rea...@li...> Sent: Friday, May 31, 2002 6:28 AM Subject: Re: [ros-kernel] native vs. Win32 - again > On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: > > OS/2 has its own graphics and windowing API: why should it use Win32? > it should at least use win32 windows and messages - that way you can > run win32 and os/2 stuff on one desktop. > getting them on one desktop with two distinct "window lists" (or however they > are stored internally) you'll have a big time trying to keep them all > up-to-date... I see where you're coming from here. I'm wondering how much of win32 it would be feasable to strip from ReactOS if the user only wants to run OS/2 apps (save some space on your 40 gig hard disk :-] ). It seems to me that in order to do this you'd have to go back to the kernel and write an OS/2 GDI/GUI, but wouldn't this be a seperate project from OS/2 binary compatibility? I have that Linux thingy that lets you run apps (recompiled to PE standard) in one common interface. I think this is fine for the odd app that no one would really want to port to the win32 GUI but it is slow and has problems. Regards, Nick. -- Nick Date Bath, England, UK --- Outgoing mail is certified virus free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Yuri P. <pro...@fr...> - 2002-05-31 05:50:30
|
On Fri, 31 May 2002 07:28:16 +0200, Patrick Mauritz wrote: >On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: >> OS/2 has its own graphics and windowing API: why should it use Win32? >it should at least use win32 windows and messages - that way you can >run win32 and os/2 stuff on one desktop. >getting them on one desktop with two distinct "window lists" (or however they >are stored internally) you'll have a big time trying to keep them all >up-to-date... Well. Question is _why_ should it use win32? _Why_ not win32k? Of couse, os2ss (and any other ss) can (and must) use common window manager and messages. But why make it depended on win32? I don't like this aproach. I consider usage of win32k graphics is ok, but usage of win32 graphics and highlevel objects is bad. I don't like to see win32-looks windows on my desktop. I prefer to see os2-style windows on my desktop. |
|
From: Patrick M. <ox...@st...> - 2002-05-31 05:30:05
|
On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: > OS/2 has its own graphics and windowing API: why should it use Win32? it should at least use win32 windows and messages - that way you can run win32 and os/2 stuff on one desktop. getting them on one desktop with two distinct "window lists" (or however they are stored internally) you'll have a big time trying to keep them all up-to-date... patrick mauritz -- > In the Beginning there was nothing, which exploded - Yeah right... < |
|
From: Patrick M. <ox...@st...> - 2002-05-31 05:27:19
|
On Fri, May 31, 2002 at 02:17:00AM +0100, Aidan Kehoe wrote:
> Yup. Note, however, that (imho) X window as a GUI _implementation_ is
> inferior to Windows NT as a GUI _implementation_ (network transparency
> notwithstanding); and I think this has some relevance to the relative
> proportions of `GUI people' and `command line' people among the two
> camps.
<irony>
well... that's completely new for... I already wonder why there
are "What's there to replace X"-questions on slashdot twice per year?
</irony>
seriously, in the unix world X has its uses ("it's there") but it should
be shot ASAP none-the-less - if you run into your favourite X advocate next
time, try some of the following:
- antialiased fonts _without API changes_ ?
- transparency _without serious API changes_ ? (of course there needs to be
something like setAlpha and getAlpha...)
but I'm getting off-topic...
the win32 GDI is only partially better, it still lacks:
- resolution independence (you know, that hack with changing the resolution
gives you a larger/smaller desktop)
- network transparency (please in a better, more highlevel way than this
X mess)
- really "common controls" - so where's the tree widget, the "cool bar", the...
ah, they are in the explorer-.dlls? _now_ I know why it's supposed to be
an "integral part" of the system...
ok - enough rant for now...
patrick mauritz
|
|
From: Joachim B. <jmb...@gm...> - 2002-05-31 05:02:45
|
"Thomas J. Hruska" <shi...@sh...> writes:
> At 01:16 PM 5/30/2002 +0200, Joachim Breuer writeth:
>>Now I will pipe in here...
>
> Me too...
>
>>Jason Filby <jas...@ya...> writes:
>>
>>Linux *administrators* got used to powerful features of the command
>>line; my administrating of said winboxen would take at least twice as
>>long without cygwin available (copy all files meeting certain criteria
>>from here to there *keeping their relative pathnames* is something cmd
>>and the explorer are not really good at - ideas welcome).
>
> How about XCOPY? It is a highly versatile copy command that I use
> regularly for backup purposes onto other drives/systems.
How do I feed my file list to xcopy? I'm not being facetious, I just
can't find it in the docs. How do I build the file list in the first
place, come to that... And then I'd probably have to fit it on the
command line, which has the (from my point of view) misfeature that
wildcard expansion is done within every single utility instead of the
shell.
foreach f ( `find . -name '*.foo' -cnewer 'whatever' | xargs grep -l 'string'` ); do
g=/somewhere/else/$f:s!pattern!whatever!
if [[ -f $g ]]; then
echo Updating $g
fi
cp $f $g
done
>>Cygwin would *almost* be an solution if win's console werent utterly
>>broken (by design). Please do not try to argue with me on that, repeat
>>after me, win's console (as it is implemented today in 2k) is UNUSABLE
>>for a command line power user. (Selection behaviour, size change
>>restrictions are the major showstoppers). OK so maybe I can run the
>>cygwin shell in an XTerm with it all sitting on 55+ compatibility
>>layers, but the fact remains that the not-worked-around basic OS
>>concept in that area is broken.
>
> I've used Linux, DOS, Win3.x, Win95/98/Me/NT/2000 and have had no problems
> or difficulties with the command prompt under Windows. Linux may have a
> powerful set of features, but I have never used more than 20% of them.
> That says that there are too many features for me. My home environment is
> DOS and over the years I have written several hundred batch files to aid me
> in day-to-day chores. I consider myself a "power user" and place heavy
> demands on the command line every single day (unless I'm busy writing a few
> thousand lines of code).
I use things like that for everyday work - and I really would miss the
"rope". This is not meant to be an offence, I'd just like to underline
that, even if it is only me who uses these features, I still miss them
where they're not available.
But scripting was not really my point, I'm used to a certain level of
command line editing (Ctrl-R foo [backward search to last command line
containing foo - it starts searching while you type, Ctrl-R again to
go to the next match, ...]) etc. pp. - These are just examples and I
really don't want to argue about it.
Let me try to put it this way: What I like about unix is not the
specific property that I have filename completion in ftp urls if I
choose so, but rather the concept that it is possible to add ftp
filename completion by calling ftp, feeding it commands and parsing
its output. Again I do not (only) like the specific feature of
programmable completion but rather that I can "plug together" unix
command line utilities arbitrarily using pipes and command line
insertion.
If other people do not require these features, fine be me - but why
should the fact that maybe 80% of the end users never touch them
deprive me of their long term availability? (Now I'm sounding personal
again... how do I put this diplomatically?)
To be very blunt: Sometimes people discussing reactos seem to say
"Let's not do this, it's featuritis". I fully agree with that basic
stance, but I would like to make a point that certain
concepts/features currently known from the unix environment cannot
easily be emulated, and so for me do not fall under "featuritis".
For those familiar with language theory: If you lack i.e. recursion
you cannot do certain things, no matter how hard you try.
>>BTW: If anyone feels like seriously thinking abouth some of these
>>'limitations' I could certainly flesh out a wishlist for 'doze from an
>>unix administrator's point of view.
>
> I know there are limitations, but I have only had to write programs on
> occasion to do what I want to do. Particularly, pipes are extremely
> limited with base OS commands (hence I wrote a program called PIPE) and
> directory depth is limited (haven't bothered to write a program). Really,
> most of the problems with the command line/batch files have to do with
> backwards campatibility issues to DOS v3.0 than anything else. Microsoft's
> trying to make people move to VBScript (yuck) so they can get rid of the
> Console API, but we can thank large companies that demand command prompt
> functionality and so both still exist (which is good for the rest of us :)
Which is what I'd dream of: Looks like win to the user, feels like
unix to the administrator. Today windows just feels "foreign" to me,
no matter how much I do with it...
To hopefully do away with the misunderstanding: Of course unifying
today's diversity of OSs is an important goal, and being able to run
all that existing software people are already used to on an open
platform will be a brilliant state of affairs.
I just want to say that I will be completely exhilerated when I can
administrate a "windows" box by leveraging all of the experience I
have with unix/posix interfaces. - Gagh, sounds like pointy haired
talk again... hope you get my drift.
Allright, I'll be quiet about that for now.
So long,
Joe
--
"I use emacs, which might be thought of as a thermonuclear
word processor."
-- Neal Stephenson, "In the beginning... was the command line"
|
|
From: Joachim B. <jmb...@gm...> - 2002-05-31 04:12:22
|
Aidan Kehoe <ke...@pa...> writes: > Ar an 30=FA l=E1 de m=ED 5, scr=EDobh Frohwalt Egerer : > > > - I can't remember much more right now. When I'm on the phone with > > Joe he always gripes about not being able to delete open files in > > Windows. > > Programs written for win32 rely on this; it's not something that > should be taken out.=20 I do want "break" the programs in that case - the "normal" delete (command and syscall) should not do it, but 'del /fo locked_file' (or whatever) should do away with it. (This mostly pertains to 'misloaded' drivers and locked log files). It would require the underlying fs being able to hold open a file descriptor to an unnamed file, and free the file when closing the descriptor. Sorry, handle. As far as I know the Win2k kernel already can do this. Same thing for rename/move. Same thing for reading open files while they're written, something like 'tail' or 'less' should be possible no matter what the other app tells us we may do to the file. At least for the administrator. Extensive wishlist will follow... ;-) So long, Joe P.S.: Further up in the thread it was said that the administrator can gain 'kill services' rights through some setting - anyone knows from the top of their head which setting that is? Thanks! --=20 "I use emacs, which might be thought of as a thermonuclear word processor." -- Neal Stephenson, "In the beginning... was the command line" |
|
From: Aidan K. <ke...@pa...> - 2002-05-31 01:17:35
|
Ar an 30ú lá de mí 5, scríobh Frohwalt Egerer : > Coming from a "pure" Linux world, I have soleley been using Windows > for the last three years and - what I would never have expected - I > really like some parts of Windoze. If that is the case, could you spell the thing properly, please? How would you like it if the fine people at Microsoft started exclusively using the term `Weenux' to describe something so many people put time and effort into? > (While I still utterly despise other parts ...) > > In these three years there was something very enlightening: My > coworkers - who are mostly really skilled software developers - > like to use the GUI. And they are amazed that I always use the > command line. > > The bottom line is - there are "command line" people and there are > "GUI" people. What interface is superior is a matter of personal > taste. So we should all stop flaming each other and get > constructive. Yup. Note, however, that (imho) X window as a GUI _implementation_ is inferior to Windows NT as a GUI _implementation_ (network transparency notwithstanding); and I think this has some relevance to the relative proportions of `GUI people' and `command line' people among the two camps. > To start with, here is my personal list of "What I don't like about > Windows and how Reactos could make it better". > > - Even if you are administrator you are not allowed to do > everything by default. (Opposed to "root" in Unix, who normally may > do everything). For example Administrator can not kill all > processes in Task manager. This is a *major* annoyance to Unix > power users working on Windows - and probably a minor issue to > fix. (It can even be configured in normal Windows by adding the > needed priviledges to the administrator account.) Yes, absolutely. Also in this area of annoying niggles are `security' measures like offering the administrator the option of disabling the Display control panel, while leaving the programmatic interface to the thing unchecked. > - The console window on Windows is really weak. Unix has gained a > lot from being able to write "terminal emulators" as normal user > mode programs. It is not too difficult to write a new terminal > emulator, so on Unix we nowadays have a plethora of really great > terminal emulators. Considering to do something "interesting" for > Windows I didn't find any good point to start, in NT the Console > seems to deeply interwoven with the rest of the system. Reactos > could improve on this by taking the "Unix Idea" of being able to > write "Terminal Emulators" in user mode. And whoops we'd have a > Win32 Reactos console, maybe one for X11 like xterm or whatever. I honestly think that the DOS console model is too limited and broken to make a decent terminal emulator program possible. The way to do it would be to wrap it around the (greatly extended) POSIX subsystem, and ignore the console entirely. > - cmd.exe is REALLY REALLY REALLY weak compared with bash or zsh. I > know bash/zsh do run on Windows, but I'd like something "native" > with the same power (programmable command line completion, good > scripting, etc.) No big issue, just a lot of work to write a really > really cool cmd.exe. Zsh runs native in win32; it can be configured to be comfortable. Integrating it into the system is worth considering--it's X11 licenced, as I recall, and less buggy than bash :-) . > - Many things do not have a command line interface. For example, > the "disk defragmenter", a bundled version of DiskKeeper can not be > started via command line. This makes sense if you want to sell > commercial versions of DiskKeeper, but it recently annoyed the hell > out of Joe (*) who tried to add a defragmentation run to his > unattended install routine. I don't think a lack of command line interfaces will really be a problem :-) , given that the compiler of the system is gcc, not VC++. > - I can't remember much more right now. When I'm on the phone with > Joe he always gripes about not being able to delete open files in > Windows. Programs written for win32 rely on this; it's not something that should be taken out. I'm only an observer at the moment, so I won't comment on the politics and motivational factors :-) . -- I'm not a pheasant plucker / I'm a pheasant plucker's son. I'm just a'plucking pheasants / 'Til the pheasant plucker comes. |
|
From: Frohwalt E. <ma...@fr...> - 2002-05-30 21:43:41
|
Hi everybody & Joe in special ... we should all lose a bit of hostility here - by leaving out the words "we" and "them". Coming from a "pure" Linux world, I have soleley been using Windows for the last three years and - what I would never have expected - I really like some parts of Windoze. (While I still utterly despise other parts ...) In these three years there was something very enlightening: My coworkers - who are mostly really skilled software developers - like to use the GUI. And they are amazed that I always use the command line. The bottom line is - there are "command line" people and there are "GUI" people. What interface is superior is a matter of personal taste. So we should all stop flaming each other and get constructive. To start with, here is my personal list of "What I don't like about Windows and how Reactos could make it better". - Even if you are administrator you are not allowed to do everything by default. (Opposed to "root" in Unix, who normally may do everything). For example Administrator can not kill all processes in Task manager. This is a *major* annoyance to Unix power users working on Windows - and probably a minor issue to fix. (It can even be configured in normal Windows by adding the needed priviledges to the administrator account.) - The console window on Windows is really weak. Unix has gained a lot from being able to write "terminal emulators" as normal user mode programs. It is not too difficult to write a new terminal emulator, so on Unix we nowadays have a plethora of really great terminal emulators. Considering to do something "interesting" for Windows I didn't find any good point to start, in NT the Console seems to deeply interwoven with the rest of the system. Reactos could improve on this by taking the "Unix Idea" of being able to write "Terminal Emulators" in user mode. And whoops we'd have a Win32 Reactos console, maybe one for X11 like xterm or whatever. - cmd.exe is REALLY REALLY REALLY weak compared with bash or zsh. I know bash/zsh do run on Windows, but I'd like something "native" with the same power (programmable command line completion, good scripting, etc.) No big issue, just a lot of work to write a really really cool cmd.exe. - Many things do not have a command line interface. For example, the "disk defragmenter", a bundled version of DiskKeeper can not be started via command line. This makes sense if you want to sell commercial versions of DiskKeeper, but it recently annoyed the hell out of Joe (*) who tried to add a defragmentation run to his unattended install routine. - I can't remember much more right now. When I'm on the phone with Joe he always gripes about not being able to delete open files in Windows. And this is to Joe: Compile your wishlist. I do not believe you will state _any_ point for "more features" that cripples compatibility with Windows. Nobody is coding following a "Windows spec". There are applications and people that are trying to make these applications run. Expressing our wishes might get exactly the people who do the coding understand us. I do not believe somebody will remember this email and implement the console window I dream of when he gets around hacking on the console (**). But if people get to implement something they might think "What might some command line person want from my app?" "How might someone like to schedule this?" Say what you want from Reactos, but do not flame it because of some email of a mailing list reader that is not among the most active developers. Cheers, Froh *= The same Joe who I am replying to. We're personal friends. **= By the way, if he does, I'll vow to send him/her a barrel of bavarian beer :-) |
|
From: Aliberti E. <ea...@us...> - 2002-05-30 21:42:53
|
On 30 May 2002 at 22:21, Casper Hornstrup wrote: > > So may I use these dlls for implementing so2ss. > > Yes you may, and I even recommend that you do. I am quite off the ros project lately, but I want to say that I dislike this approach. > > the graphics architecture is not too comon to me. > > Is it this way possible to draw lines and use windows as a win32 app > > would be able to? > > Yes. If your OS/2 subsystem DLLs link with gdi32.dll you can use > drawing primitives to perform drawing activities. Use user32.dll for > higher level objects such as windows, menus and messages. OS/2 has its own graphics and windowing API: why should it use Win32? > > With other words: Has csrss.exe much to do with windowing. > > No. Csrss.exe handles consoles and access to the blue screen device. I propose to rename that server "w32ss.exe". It is no more a c/s run- time and our implementation is not plug-in based (=DLL based). |
|
From: Casper H. <ch...@us...> - 2002-05-30 20:29:26
|
tor, 2002-05-30 kl. 20:27 skrev Robert K.: > So may I use these dlls for implementing so2ss. Yes you may, and I even recommend that you do. > the graphics architecture is not too comon to me. > Is it this way possible to draw lines and use windows as a win32 app would > be able to? Yes. If your OS/2 subsystem DLLs link with gdi32.dll you can use drawing primitives to perform drawing activities. Use user32.dll for higher level objects such as windows, menus and messages. > With other words: Has csrss.exe much to do with windowing. No. Csrss.exe handles consoles and access to the blue screen device. - Casper |
|
From: Diego I. <ias...@ac...> - 2002-05-30 19:47:20
|
I am ready, hopefuly they are online somewhere. did you get my last email? - diego On Wednesday 29 May 2002 09:26, Steven Edwards wrote: > > At 02.33 29/05/2002, you wrote: > > >ONE MORE TIME - If anyone is feeling frisky and wants to help on my > > >WINE > > >work email me already. > > > > Sorry, I'd help, but I always try to avoid anything involving > > shell scripts :-( > > All that is really needed is "something" that > > 1. Runs ./configure > 2. Converts the Makefiles. > > It could be a small c program that parses the Makefiles and imports them > in to reactos makefiles. I really don't care at this point, hell even > bringing out the ducktape and using Perl would be fine as it wont be > part of the standard build process. > > Thanks > Steven > > "Every revolution was once a thought in one man's mind" > - Ralph Waldo Emerson > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel -- October 12, the Discovery. It was wonderful to find America, but it would have been more wonderful to miss it. -- Mark Twain, "Pudd'nhead Wilson's Calendar" |
|
From: Steven E. <ste...@ya...> - 2002-05-30 18:41:08
|
> So may I use these dlls for implementing so2ss. > > the graphics architecture is not too comon to me. > Is it this way possible to draw lines and use > windows as a win32 app would > be able to? > With other words: Has csrss.exe much to do with > windowing. You should be able to use GDI32 and USER32 they make the needed calls to win32k.sys for Windowing. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Robert K. <ro...@ko...> - 2002-05-30 18:26:42
|
So may I use these dlls for implementing so2ss. the graphics architecture is not too comon to me. Is it this way possible to draw lines and use windows as a win32 app would be able to? With other words: Has csrss.exe much to do with windowing. Casper Hornstrup schrieb: > tor, 2002-05-30 kl. 01:37 skrev Robert K.: > > The native vs. Win32 theme again. > > > > WHICH DLLs become native now? > > Those lower level Win32 DLLs that links directly with ntdll.dll now will > become native DLLs. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Casper H. <ch...@us...> - 2002-05-30 17:58:51
|
tor, 2002-05-30 kl. 18:47 skrev Iain Shigeoka: > On 5/29/02 6:09 PM, "Rex Jolliff" <re...@lv...> wrote: > > The OpenWatcom.org project is using it and the watcom compiler project may > be a great partner for reactos (ming always feels like a poor second cousin > to a native windows compiler)... > > Anyhow, just a suggestion. We have several advantages when using/supporting only gcc/binutils. they are present on a lot of platforms. This means less work for us when we expand to these platforms. By supporting only one compiler we don't have to be so strict about about following every standard out there or have workarounds for missing features of other compilers. We can use gcc specific features because we know they are there. If you look at binutils and gcc projects which must compile with many different compilers and versions of those, you will see that there are many guidelines that must be followed when submitting patches to these projects. This is one reason (of many), that it is difficult to get patches into these projects. GCC is not just a C/C++ compiler. It is designed to have "plugin" frontends written for it to support many languages. When the GPC frontend is included in the official releases, there really is no valid reasons left for keeping Pascal programmers away from ReactOS anymore. - Casper |
|
From: Iain S. <iai...@me...> - 2002-05-30 17:08:00
|
On 5/29/02 6:09 PM, "Rex Jolliff" <re...@lv...> wrote: > At 07:13 PM 5/28/02 -0700, you wrote: >> Maybe we can switch to a better revision control system. There was an >> article on slashdot about bitkeeper. It has a strange status (not open >> source), but it is used for linux kernel. > > I have looked at other revision control systems in the past, and didn't > find any that meets my needs for free. There is ClearCase if you want the > Cadillac of such systems, but its a burden to configure and maintain, > not to mention real pricey. CVS has been around a long time and is > solid and meets our needs. It has the limitation that it cannot track > movement of files, and I agree this is a nasty limitation to have, but > we can live with it, as Jason or I will do the bulk moves needed to > satisfy the new layout. A non-open source but free to open source projects alternative is perforce (www.perforce.com). This is a commercial VCS that is simple, crossplatform, powerful and fast fast fast. The server is pretty much zero-administration. It comes with a feature which lets you create trouble tickets (jobs) and then associate them with changes so submissions close them. You can customize jobs to serve as a nice, lightweight bug tracking system, or use their API to integrate with other bug tracking systems (they already have a free module to integrate with bugzilla). You can move or rename files while retaining history across these changes, etc etc etc. The OpenWatcom.org project is using it and the watcom compiler project may be a great partner for reactos (ming always feels like a poor second cousin to a native windows compiler)... Anyhow, just a suggestion. -iain |
|
From: Thomas J. H. <shi...@sh...> - 2002-05-30 12:50:18
|
At 01:16 PM 5/30/2002 +0200, Joachim Breuer writeth:
>Now I will pipe in here...
Me too...
>Jason Filby <jas...@ya...> writes:
>
>Linux *administrators* got used to powerful features of the command
>line; my administrating of said winboxen would take at least twice as
>long without cygwin available (copy all files meeting certain criteria
>from here to there *keeping their relative pathnames* is something cmd
>and the explorer are not really good at - ideas welcome).
How about XCOPY? It is a highly versatile copy command that I use
regularly for backup purposes onto other drives/systems.
>Cygwin would *almost* be an solution if win's console werent utterly
>broken (by design). Please do not try to argue with me on that, repeat
>after me, win's console (as it is implemented today in 2k) is UNUSABLE
>for a command line power user. (Selection behaviour, size change
>restrictions are the major showstoppers). OK so maybe I can run the
>cygwin shell in an XTerm with it all sitting on 55+ compatibility
>layers, but the fact remains that the not-worked-around basic OS
>concept in that area is broken.
I've used Linux, DOS, Win3.x, Win95/98/Me/NT/2000 and have had no problems
or difficulties with the command prompt under Windows. Linux may have a
powerful set of features, but I have never used more than 20% of them.
That says that there are too many features for me. My home environment is
DOS and over the years I have written several hundred batch files to aid me
in day-to-day chores. I consider myself a "power user" and place heavy
demands on the command line every single day (unless I'm busy writing a few
thousand lines of code).
>BTW: If anyone feels like seriously thinking abouth some of these
>'limitations' I could certainly flesh out a wishlist for 'doze from an
>unix administrator's point of view.
I know there are limitations, but I have only had to write programs on
occasion to do what I want to do. Particularly, pipes are extremely
limited with base OS commands (hence I wrote a program called PIPE) and
directory depth is limited (haven't bothered to write a program). Really,
most of the problems with the command line/batch files have to do with
backwards campatibility issues to DOS v3.0 than anything else. Microsoft's
trying to make people move to VBScript (yuck) so they can get rid of the
Console API, but we can thank large companies that demand command prompt
functionality and so both still exist (which is good for the rest of us :)
Hope this helps!
Thomas J. Hruska -- shi...@sh...
Shining Light Productions -- "Meeting the needs of fellow programmers"
http://www.shininglightpro.com/
|
|
From: Casper H. <ch...@us...> - 2002-05-30 12:01:41
|
tor, 2002-05-30 kl. 09:14 skrev Patrick Mauritz:
> On Thu, May 30, 2002 at 04:43:20AM +0200, Casper Hornstrup wrote:
> > * Easier repeated merging. A pain to do with CVS. You have to be very
> > careful.
> what exactly do you mean by this?
If you have one branch (say TRUNK), create another branch (say
BRANCH), and then later want to merge all changes made on TRUNK after
BRANCH was created to BRANCH. This will CVS do just fine. Now, when you
next time perform the merge again (+ all never changes on TRUNK), then
CVS will not remember that you have already merged some of the changes
to BRANCH and you will have a lot of conflicts. To avoid this with CVS,
you can tag the TRUNK branch when you do a merge and then merge changes
from the last tag you made (or the branch point the first time) to the
new tag. If you forget to tag TRUNK, you are out of luck; prepare
yourself for conflicts.
> > * Extensible through plugins. To allow for greater customization.
> - SVN: can be configured for that
> - Arch: doesn't support it for a reason: a respository should work
> for everyone without having to care for client side extensions
> (there is no real "server")
Well, I don't believe in the idea of software that is so good that it
can be used for any purpose.
>
> > * Per module/directory/file access control.
> on module-boundaries: does even exist with CVS, needs server access
> the other things: why? either you want to give access to the source
> or you don't
You might give read access for some to an area, and read/write access to
another.
>
> > * Delayed transactions. If I wanted to ensure that a project at least
> > compiles after a patch is committed, then the transaction could be
> > put in a delayed state and then an external program is run to apply
> > the patch and then try to compile the project. If the compile is
> > successful then the transaction can be committed. If not, then
> > transaction is rolled back. This could be used with a regressioYn
> > framework too, thereby achieving a more stable code base.
> why can't you do this on your own box?
You can - and should, but for some reason it does not work on large
projects. If you monitor the WINE and Subversion bug lists, you will
notice that there are regularly regressions in their projects (and it is
arrogant to say that we don't have them -- we just have no way of
immediately spotting them -- yet). We can say that the regressions are
there because these projects have bad software engineers, but I choose
to believe it is because the tools that are used, does very little to
help keep regressions out of the code base.
Today we have only two configurations, but still we have sometimes had
code in CVS that would not compile. Bad programmers or human
limitations? Do you want to spend half an hour, doing a clean build of
ReactOS in these two configurations after each little patch you've
created? What will happen when ReactOS is ported to many more platforms?
I doubt it will be any easier to do manually so why not set up a box to
take care of such things?
>
> > * Able to exclude certain paths from a working copy. Eg. for this
> > particular working copy I only need /dir1 and /dir2 but not
> > /dir1/subdir1 so don't update them when I update the working copy.
> - that could work with CVS, but not with SVN or Arch as both of them
> always do versioning over the whole tree, not over single files
Still, the client could choose to ignore some paths.
|
|
From: Joachim B. <jmb...@gm...> - 2002-05-30 11:17:40
|
Now I will pipe in here... Jason Filby <jas...@ya...> writes: > --- Nick Date <nic...@ya...> wrote: >>I was reacting. The reason ReactOS was being slated was, I suspect, >>because Linux people see ROS as a threat rather than an ally. They >>see a potentially superior and more mainstream-compatible kernel >>and they poo their pants. > > I don't know how all Linux people perceive ReactOS, generally I think > a lot of them don't know everything about what we're doing. At > wineconf it was surprising how many people didn't know much about > what we were doing. However, they were very interested to listen. It > doesn't really matter if some (and you can't generalize about all of > them) people in the Linux community see us as a threat (_if_ they > do). I think we should just focus on promoting ourselves as an ally > with them. I am an "ardent" linux user. And I also have to support Win(mostly 2k) boxen in my "commercial" life (icky administration stuff). >>I went to the forum with no preconception and I was flamed by about >>3 people who blatantly spent their entire lives with their eyes >>glued to a "VDU". > > Well, that's their lose, and we know that. But I'm very sure not all > people who use Linux are flamers. > >>Maybe ROS is too "Windozey" for Linux users? I don't know, but I >>don't think you should have to have a degree in Computer Science to >>install an OS (which is why I use Win XP). Looking at the neighbouring thread about the Posix subsystem, I will try a guess at the reasons the hostile attitude might come from. Linux *administrators* got used to powerful features of the command line; my administrating of said winboxen would take at least twice as long without cygwin available (copy all files meeting certain criteria from here to there *keeping their relative pathnames* is something cmd and the explorer are not really good at - ideas welcome). Cygwin would *almost* be an solution if win's console werent utterly broken (by design). Please do not try to argue with me on that, repeat after me, win's console (as it is implemented today in 2k) is UNUSABLE for a command line power user. (Selection behaviour, size change restrictions are the major showstoppers). OK so maybe I can run the cygwin shell in an XTerm with it all sitting on 55+ compatibility layers, but the fact remains that the not-worked-around basic OS concept in that area is broken. So the last thing 'we unix administrators' would like to see created is a compatible alternative to windows which is improved in enough areas to be interesting to end users/decision makers (price, maybe?); but still completely lacks usability in 'our' sense. That's why 'we' (I, at least) would like to see reactos go in the usable (for us) direction. [There is no we]. With that in mind, people like me with an admittedly limited understanding of the inner workings of either reactos or NT get a little edgy when people say things that sound like "let's not overdo this posix thing, if windows apps ( can interact with posix apps / see the posix namespace / may use posix semantics with syscalls ) that will break compatibility of apps written to that concept with the original windows". I certainly wouldn't mind an open OS that can run M$-Ware, but if in that OS the concious design decision is made that all apps developable for that OS must also run under Windows - i.e. it is conciously limited in certain areas - I certainly wonder about its usefulness. A "windows compatibility certification mode" (or just "win32ss visible only mode"), maybe per-process, would certainly be useful - but if I want to do "cmd.exe -c type diskimage > \dev\fd0" why won't you let me? I wrote about similar aspects of that frustration before - I *know* the OS can do it (rename/delete open files, kill services, ...); but the UI/API just won't let me. Sometimes it does by making you bend over backwards (in the resource kit ISTR a service killer which does what it does by introducing an RPC interface to the relevant functions - which is also open to the network...), but not through the standard path. I don't mind a "Yes I'll shoot myself in the foot now, do it anyway" '--really-do-this-against-the-specs' flag, but being forbidden to do things at all is, indeed, limiting. If something in here could be interpreted as a flame please note that it is not intended as such and probably a result of English not being my mother tongue. BTW: If anyone feels like seriously thinking abouth some of these 'limitations' I could certainly flesh out a wishlist for 'doze from an unix administrator's point of view. So long, Joe -- "I use emacs, which might be thought of as a thermonuclear word processor." -- Neal Stephenson, "In the beginning... was the command line" |
|
From: Patrick M. <ox...@st...> - 2002-05-30 07:15:43
|
On Thu, May 30, 2002 at 04:43:20AM +0200, Casper Hornstrup wrote: > CVS is great...when compared to having no version control system. This > does not mean it cannot be improved upon. Some features I would like to > see in a version control system includes: ok, let's compare subversion (aka. SVN, http://subversion.tigris.org) and arch (www.regexps.com) against your wishes, both are free > * Atomicity and scalable. CVS uses many locks. - SVN+Arch: atomic commits - commit the whole set or nothing of it revisions are per-change, not per-change-of-file > * Versioned directories, renames, and moves. - SVN: versioned source tree, renames and moved explicitely (svn cp, svn mv...) - Arch: same as SVN, but also supports file tags for renames and moves (ie. have "tag: some_unique_identifier" in the file header and this file _is_ unique with no special attention to be taken for the VCS) > * Able to do more offline. Eg. the diffs used for the last > update could be cached. - SVN+Arch: a complete original tree is present on the local box, in .svn or {arch} which is used for diffs etc > * Easier repeated merging. A pain to do with CVS. You have to be very > careful. what exactly do you mean by this? > * Better handling of binary files. Arch takes care of this for sure, I think SVN does as well (dunno) > * Fewer conlicts. Some smart person could probably figure out how to > achieve this. by using something more sensible than diff/patch? maybe - but I don't know such a thing (except for the sccs-format maybe) > * Extensible through plugins. To allow for greater customization. - SVN: can be configured for that - Arch: doesn't support it for a reason: a respository should work for everyone without having to care for client side extensions (there is no real "server") > * Per module/directory/file access control. on module-boundaries: does even exist with CVS, needs server access the other things: why? either you want to give access to the source or you don't > * Issue tracking system integration. Eg. if I commit a patch with a > log message containing the tags "@issue ros10 @status fixed", then > the issue tracking system would be notified that the issue with ID > "ros10" should have status "fixed". - SVN: I guess they'll do something like that (compare: scarab.tigris.org which is a sibling-project) - Arch: again, I guess sth. like that will be done - this time it's called labnotes > * Delayed transactions. If I wanted to ensure that a project at least > compiles after a patch is committed, then the transaction could be > put in a delayed state and then an external program is run to apply > the patch and then try to compile the project. If the compile is > successful then the transaction can be committed. If not, then > transaction is rolled back. This could be used with a regression > framework too, thereby achieving a more stable code base. why can't you do this on your own box? > * Able to exclude certain paths from a working copy. Eg. for this > particular working copy I only need /dir1 and /dir2 but not > /dir1/subdir1 so don't update them when I update the working copy. - that could work with CVS, but not with SVN or Arch as both of them always do versioning over the whole tree, not over single files > * Assign meta data to files and directories. Versioned of course. - SVN has full metadata support (ie. put any junk you want into it) - Arch supports filesystem metadata > * Symbolic links. Cross repository symlinks too. OSS projects tend to > depend on each other so why not have a symlink in a repository > pointing to a path in another projects repository? Then you would > only need one URL as the version control system could transparently > follow symlinks to the other repositories. - SVN+Arch: internal symlinks should be supported - Arch: as you can branch (with the ability to merge forth and back) over server boundaries (as strictly speaking there is no "server") that can be done easily as long as the other project is also arch-controlled some further description to arch (eg. why I insist that there is no server): arch is designed to work on a local directory as repository which is enhanced by some "virtual file system"-library which maps normal access to ftp transparently for that process. there are patches to map onto sftp, webdav and rsync as well, iirc. after creating a local repository, you can branch off a remote one and work (with full versioning) in your local repo with the ability to merge new patchsets from the original place to the new one and back. so it's not as there aren't any free VCS except CVS, it's just that they're quite new and not yet in the 1.0 stage... sincerely, patrick mauritz -- ,------------------------------------------------------------------------. > In the Beginning there was nothing, which exploded - Yeah right... < |------------------------------------------------------------------------| > The Forthcoming OpenBIOS | www.freiburg.linux.de/openbios < `------------------------------------------------------------------------' Understanding yourself without understanding your enemy only gives you half a chance of victory |
|
From: Casper H. <ch...@us...> - 2002-05-30 02:50:36
|
tor, 2002-05-30 kl. 03:09 skrev Rex Jolliff:
> At 07:13 PM 5/28/02 -0700, you wrote:
> >Maybe we can switch to a better revision control system. There was an
> >article on slashdot about bitkeeper. It has a strange status (not open
> >source), but it is used for linux kernel.
>
> I have looked at other revision control systems in the past, and didn't
> find any that meets my needs for free. There is ClearCase if you want the
> Cadillac of such systems, but its a burden to configure and maintain,
> not to mention real pricey. CVS has been around a long time and is
> solid and meets our needs. It has the limitation that it cannot track
> movement of files, and I agree this is a nasty limitation to have, but
> we can live with it, as Jason or I will do the bulk moves needed to
> satisfy the new layout.
>
> I really don't have time to acquire, install, configure and maintain a
> new revision control system these days, I still haven't even found time
> to setup cvsup for Brian (I'll try this weekend, honest :-)). So, unless
> I hear some very compelling arguments for another system, my vote
> is to stay with CVS.
>
>
> Rex Jolliff
> re...@lv...
CVS is great...when compared to having no version control system. This
does not mean it cannot be improved upon. Some features I would like to
see in a version control system includes:
* Atomicity and scalable. CVS uses many locks.
* Versioned directories, renames, and moves.
* Able to do more offline. Eg. the diffs used for the last
update could be cached.
* Easier repeated merging. A pain to do with CVS. You have to be very
careful.
* Better handling of binary files.
* Fewer conlicts. Some smart person could probably figure out how to
achieve this.
* Extensible through plugins. To allow for greater customization.
* Per module/directory/file access control.
* Issue tracking system integration. Eg. if I commit a patch with a
log message containing the tags "@issue ros10 @status fixed", then
the issue tracking system would be notified that the issue with ID
"ros10" should have status "fixed".
* Delayed transactions. If I wanted to ensure that a project at least
compiles after a patch is committed, then the transaction could be
put in a delayed state and then an external program is run to apply
the patch and then try to compile the project. If the compile is
successful then the transaction can be committed. If not, then
transaction is rolled back. This could be used with a regression
framework too, thereby achieving a more stable code base.
* Able to exclude certain paths from a working copy. Eg. for this
particular working copy I only need /dir1 and /dir2 but not
/dir1/subdir1 so don't update them when I update the working copy.
* Assign meta data to files and directories. Versioned of course.
* Symbolic links. Cross repository symlinks too. OSS projects tend to
depend on each other so why not have a symlink in a repository
pointing to a path in another projects repository? Then you would
only need one URL as the version control system could transparently
follow symlinks to the other repositories.
- Casper
|
|
From: Rex J. <re...@lv...> - 2002-05-30 01:08:51
|
At 07:13 PM 5/28/02 -0700, you wrote: >Maybe we can switch to a better revision control system. There was an >article on slashdot about bitkeeper. It has a strange status (not open >source), but it is used for linux kernel. I have looked at other revision control systems in the past, and didn't find any that meets my needs for free. There is ClearCase if you want the Cadillac of such systems, but its a burden to configure and maintain, not to mention real pricey. CVS has been around a long time and is solid and meets our needs. It has the limitation that it cannot track movement of files, and I agree this is a nasty limitation to have, but we can live with it, as Jason or I will do the bulk moves needed to satisfy the new layout. I really don't have time to acquire, install, configure and maintain a new revision control system these days, I still haven't even found time to setup cvsup for Brian (I'll try this weekend, honest :-)). So, unless I hear some very compelling arguments for another system, my vote is to stay with CVS. Rex Jolliff re...@lv... |
|
From: Casper H. <ch...@us...> - 2002-05-30 00:09:14
|
tor, 2002-05-30 kl. 01:37 skrev Robert K.: > The native vs. Win32 theme again. > > WHICH DLLs become native now? Those lower level Win32 DLLs that links directly with ntdll.dll now will become native DLLs. |
|
From: Robert K. <ro...@ko...> - 2002-05-29 23:36:50
|
The native vs. Win32 theme again. I think David convinced me that it would be better to have basic win32-dlls as native-dlls. An architecture with sub systems tends to duplicate code. However some code is nearly made to be reused by different sub systems. If the advapi, gdi, user and winsock APIs were native, it would make my os2 developement much less work intensive. kernel is not so importand for me 'cos it implements already too much sub system (for my flavor). However having direct access to the GUI makes os2-apps in some kind indipendent from win32. A sockets lib and advapi as native prevents from implementing things over and over. WHICH DLLs become native now? consider also making one or more native-dlls and let the original win32-dlls make calls to the new. |
8 messages has been excluded from this view by a project administrator.
