Menu
▾
▴
reactos-kernel
|
From: Jarmo M. <ja...@mu...> - 2002-07-20 05:16:26
|
Has anyone pressed Num Pad * when focus is in Network Neighborhood (or Computers Near Me)? This operation will expand A LOT and it cannot be stopped! You have to kill the process. Pressing Esc would be nice way to stop it and a Stop button. One more annoying thing that comes to mind. When you paste files (Copy and Paste) to one folder and switch to another folder, Explorer activates the previous folder when it displays Copy progress dialog. So, no call to SetForegroundWindow, please. JMu ----- Original Message ----- From: "Royce Mitchell III" <ro...@ev...> To: <rea...@li...> Sent: Saturday, July 20, 2002 6:53 AM Subject: Re: [ros-kernel] Re: ROS gui > > Why should we clone explorer? If we use a free one or wite a free one, if > > the person doesn't like it could they just not download the newest > > explorer. > > I think an Explorer clone should adhere closely to the "interface" of the > original, so newbies will be immediately familiar with it. Just because MS's > is insecure, doesn't mean ours has to be. > > Here's an impartial feature/non-feature list for an explorer clone: > > * keep quick-launch > * keep in-situ start menu editing > * remove start menu reordering ( should always alphabetize ) > * remove "web view" > * keep desktop > * everything can be customized, and should be easy to do so ( no editing > text files - that's a Linux thing ) > * it should be possible to edit settings in a text file - if you want to ( a > single, simple ini file - there are several reasons for this one if you want > me to expound ) > * keep control panel > * xp-like start menu ( it really is a much better layout when you get rid of > the performance-sapping fancy graphics ) > * xp-like user management ( ms finally got that right, if xp wasn't such a > flop ) > * extension hiding should *not* be default for power users. > * file hiding should *not* be default for power users. > * no web-integration. web browser must be a separate app. > * There should *never* be any reason for the OS to open a file unless the > user has performed some action on the file, or on a program that uses the > file. ( This will eliminate some of the nastier security holes explorer has > been plagued by ). > * file associations could work MUCH better. It's always a pain setting up my > .c, .h, .cpp, .hpp, etc associations. > * there's no reason for explorer to access 20 registry entries every time > you double-click something. It should be blind to settings changes made > directly to it's config files/registry. All settings should be available > from within the program so that it's not necessary to edit the config > files/reg directly. At the very least it should re-read it's settings unless > it detects they have changed. ( Probably would have to be an ini file to > monitor for file changes ). > * 9x/NT4-like network neighborhood, unless someone can explain to me how the > 2000/XP net hoods are better ( I have yet to find a good reason ). Note I'm > talking about browsing the network here, not configuring it. > * this isn't just for explorer... but there should be very little ( ideally > none ) images/animations included. They just slow the O/S down. If they are > necessary, then they should not be loaded until the first time they are > needed. > > That's all I can think of right now. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: James M. <jid...@sa...> - 2002-07-20 05:49:54
|
Okay, I was thinking that he was talking about explorer the browser not t= he=20 shell interface. The shell should be replaceable with something that the = user=20 wants. It would seem to me that this is a flaw in design, unless you allo= w=20 things like themes which can change all the button and other widget style= s=20 along with the window apperance and things of this nature. James Marjie |
|
From: Robert K. <ro...@ko...> - 2002-07-20 10:31:06
|
> > >Okay, I was thinking that he was talking about explorer the browser not the >shell interface. The shell should be replaceable with something that the user >wants. It would seem to me that this is a flaw in design, unless you allow >things like themes which can change all the button and other widget styles >along with the window apperance and things of this nature. > What you think of ist a customizable GUI. The actual windwos and buttons are drawn by a lib. A Shellprogram gives an more less universal interface to the OS/its files and should not provide Skins ot th. like that. > >James Marjie > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > |
|
From: Robert K. <ro...@ko...> - 2002-07-20 10:34:23
|
Do you also know these people? Word belongs to Windows. Explorer is the OS/windows. A display runs sometimes in DOS-mode. The internet is an application on the desktop and consists of just HTML sites. It belongs to either AOL or M$ who maintains all the content (including warez-sites?) ! Richard Campbell schrieb: > I think you guys need to stop thinking like geeks and start thinking > like AOLers... (i.e. explorer DOES need to be cloned because it is > part of windows nt.) > > PS, I've missed out on alot of ROS development (although very few > people have missed my flames I'm sure :)) I hope to be up to speed > > >> From: rea...@li... >> Reply-To: rea...@li... >> To: rea...@li... >> Subject: reactos-kernel digest, Vol 1 #239 - 13 msgs >> Date: Thu, 18 Jul 2002 12:10:27 -0700 >> >> Send reactos-kernel mailing list submissions to >> rea...@li... >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/reactos-kernel >> or, via email, send a message with subject or body 'help' to >> rea...@li... >> >> You can reach the person managing the list at >> rea...@li... >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of reactos-kernel digest..." >> >> >> Today's Topics: >> >> 1. =?iso-8859-1?Q?YAW:_yet_another_windows_(old_project)?= >> (=?utf-8?Q?ea...@io...?=) >> 2. Re: YAW: yet another windows (old project) (Royce Mitchell III) >> 3. Re: YAW: yet another windows (old project) (Thomas J. Hruska) >> 4. Re: finally got good stack trace... (David Welch) >> 5. Re: The Explorer replacement we need. (KJK::Hyperion) >> 6. FW: Proposal - alt.os.reactos Discussion forum for the OpenSource >> WindowsNT/2K clone ReactOS (Steven Edwards) >> 7. newsgroup (Steven Edwards) >> 8. Re: newsgroup (David Welch) >> 9. Re: newsgroup (Steven Edwards) >> 10. Re: finally got good stack trace... (Eric Kohl) >> 11. Re: finally got good stack trace... (Royce Mitchell III) >> 12. Re: The Explorer replacement we need. (Nick Date) >> 13. Re: The Explorer replacement we need. >> (=?iso-8859-2?Q?H=E1morszky_Bal=E1zs?=) >> >> --__--__-- >> >> Message: 1 >> Date: Wed, 17 Jul 2002 14:37:44 +0200 >> From: "=?utf-8?Q?ea...@io...?=" <ea...@io...> >> To: rea...@li... >> Subject: [ros-kernel] >> =?iso-8859-1?Q?YAW:_yet_another_windows_(old_project)?= >> Reply-To: rea...@li... >> >> SXMgaXQgYSBkZWFkIHByb2plY3Q/DQoNCmh0dHA6Ly93d3cuaWNlLnJ1L3lhdy8= >> >> >> >> >> --__--__-- >> >> Message: 2 >> Date: Wed, 17 Jul 2002 15:17:04 -0600 (Central Standard Time) >> From: Royce Mitchell III <ro...@ev...> >> To: rea...@li... >> Subject: Re: [ros-kernel] YAW: yet another windows (old project) >> Reply-To: rea...@li... >> >> That's the impression I got when I checked them out a few >> weeks ago. >> >> Royce3 >> >> > >> >Subject: [ros-kernel] YAW: yet another windows (old project) >> > From: "=?utf-8?Q?ea...@io...?=" <ea...@io...> >> > Date: Wed, 17 Jul 2002 14:37:44 +0200 >> > To: rea...@li... >> > >> >SXMgaXQgYSBkZWFkIHByb2plY3Q/DQoNCmh0dHA6Ly93d3cuaWNlLnJ1L3lhdy8= >> > >> > >> > >> > >> >------------------------------------------------------- >> >This sf.net email is sponsored by:ThinkGeek >> >Welcome to geek heaven. >> >http://thinkgeek.com/sf >> >_______________________________________________ >> >reactos-kernel mailing list >> >rea...@li... >> >https://lists.sourceforge.net/lists/listinfo/reactos-kernel >> >> >> >> --__--__-- >> >> Message: 3 >> Date: Wed, 17 Jul 2002 16:08:06 -0400 >> To: rea...@li... >> From: "Thomas J. Hruska" <shi...@sh...> >> Subject: Re: [ros-kernel] YAW: yet another windows (old project) >> Reply-To: rea...@li... >> >> At 02:37 PM 7/17/2002 +0200, =?utf-8?Q?ea...@io...?= writeth: >> >SXMgaXQgYSBkZWFkIHByb2plY3Q/DQoNCmh0dHA6Ly93d3cuaWNlLnJ1L3lhdy8= >> >> For those who can't read/speak/understand the Base64 language: >> ------------Start of Base64 Decode--------------- >> Is it a dead project? >> >> http://www.ice.ru/yaw/ >> -------------End of Base64 Decode---------------- >> >> Hope this helps! >> >> >> Thomas J. Hruska -- shi...@sh... >> Shining Light Productions -- "Meeting the needs of fellow programmers" >> http://www.shininglightpro.com/ >> >> >> --__--__-- >> >> Message: 4 >> Date: Wed, 17 Jul 2002 22:07:52 +0000 >> From: David Welch <we...@cw...> >> To: rea...@li... >> Subject: Re: [ros-kernel] finally got good stack trace... >> Reply-To: rea...@li... >> >> On Tue, Jul 16, 2002 at 10:26:26PM -0500, Royce Mitchell III wrote: >> > Any ideas? >> > >> Yes, ntoskrnl is an exception, just add 0xc0000000 to the printed >> address when using addr2line. I'm sorry figuring out where the kernel >> crashed >> can be such a bear. >> >> > It is still reporting div/0 by the way, and I have latest CVS... >> > >> Seems to be working here. >> >> >> >> --__--__-- >> >> Message: 5 >> Date: Wed, 17 Jul 2002 23:04:47 +0200 >> To: rea...@li... >> From: "KJK::Hyperion" <no...@li...> >> Subject: Re: [ros-kernel] The Explorer replacement we need. >> Reply-To: rea...@li... >> >> At 20.25 17/07/2002, you wrote: >> >Also wine has some bugs with its CxxFrameHandler >> >> what's this? >> >> >Dont get me wrong I am not oposed to a project to rewrite explorer.exe. >> >> and I'm not supporting such a project :-) Explorer isn't exactly the >> best >> desktop around, it's Shell32 that matters >> >> >1. It doesnt link to msvcp60.dll >> >> C++ runtime? whoa, it's big. It implements the STL, I see. We could use >> STLPort for this, it's the STL the OpenOffice guys are using, and it >> looks >> good (http://www.stlport.org/). The problem is that the DLL uses >> Microsoft's C++ name decoration. I started documenting their decoration >> scheme some time ago, but I can't find the BNF grammar I hacked together >> anymore. If you need help on adding this to g++, I can try >> reconstructing >> what I had found out >> >> >4. After only 1 day of work I can now compile 50% of geoShell under >> >mingw/gcc 3.1. I was working on litestep I would be banging my head >> in to >> >the wall right now. >> >> ;-) >> >> > > but was is usable? would you use it? I downloaded it >> > > and gave it a try, and >> > > my answer is ... >> >I was using it....the only real problem I had was the lack of >> Desktop Icons. >> >> me too. Anyway, what do you think of my idea of the desktop as an >> always-on-bottom bar with a Desktop widget in it? >> >> > > ... nope, geoshell is not ready for "prime time". It >> > > didn't even *work* for >> > > me. Some menus didn't open, some plugins behaved >> > > odd, some menus flickered. >> > > A disappointment >> >The only thig left that really bothers me is so bugs in minamizing the >> >geobars. >> >> I noticed a long series of bug and quirks, instead. The Favorites menu >> doesn't open (not that I really miss it, since I use Opera full-time). >> There's a duplicate Programs menu because I have a localized Windows >> and it >> was expecting the folder to be literally called "Programs". The "lock >> screen" doesn't lock the screen at all, it starts the screen saver. Some >> control panel applets had the wrong icon or caption. Some icons appeared >> shrunk. If you want a full bug report, I can reinstall geOShell >> >> >I agree adding stuff to the bars could be better... I think the size of >> >the default geObar doesnt help to much. >> >> that's why Office (and most programs with similar toolbars) has a >> separate >> dialog >> >> [...] >> >Come on dude how hard is it to rename the resources? >> >> I think you misunderstood me. I'm just pointing out usability problems. >> Mine is a designer's point of view, not a developer's. But if it's >> easy to >> solve, even better :-) >> >> [...] >> >I dont see why we couldnt implement this if we adopt R4. they are >> working >> >on R6 but are willing to help us if we do future development on R4 >> for ReactOS. >> >> again: it's not (strictly) a technical matter. I just want an opinion >> on my >> remarks: do they make sense to you? do you agree? anything to add? >> >> BTW, I didn't ask directly to the geOShell team because I was afraid >> they >> were a bit too "1337" to understand usability arguments (no offense >> meant, >> I just seem to have strange prejudices against IRC'ers) >> >> >> >> --__--__-- >> >> Message: 6 >> Date: Wed, 17 Jul 2002 23:50:23 -0700 (PDT) >> From: Steven Edwards <ste...@ya...> >> To: rea...@li... >> Subject: [ros-kernel] FW: Proposal - alt.os.reactos Discussion forum >> for the OpenSource WindowsNT/2K clone ReactOS >> Reply-To: rea...@li... >> >> Proposal - alt.os.reactos Discussion forum for the >> OpenSource WindowsNT/2K clone ReactOS >> >> CHARTER: alt.os.reactos discusses design and >> implementation of the ReactOS operating systems and >> its >> relation to the Microsoft Windows Operating Systems. >> Subjects will include but not be limited to >> device drivers, win32api support, the posix subsystem >> and license issues X11/BSD and GNU GPL/LGPL. >> >> The newsgroup will not be moderated. Binary, >> off-topic, spam and advertising posts are not >> permitted. >> Discussion of hacks, cracks, warez, serial numbers or >> the illegal exchange of copyrighted software is >> banned. >> >> JUSTIFICATION: A scan of messages in Google Groups in >> the 3 months from 5/17/98 to 7/17/98 showed >> *exactly* 1,010 relevant matches discussing ReactOS. >> ReactOS is the key topic of no less then 3 >> mailing lists and 2 web message boards and as such >> central repository such as a news group would be >> convenient. >> >> Thanks >> Steven Edwards >> >> -- >> "Every revolution was once a thought in one man's >> mind" >> - Ralph Waldo Emerson >> >> >> __________________________________________________ >> Do You Yahoo!? >> Yahoo! Autos - Get free new car price quotes >> http://autos.yahoo.com >> >> >> --__--__-- >> >> Message: 7 >> Date: Wed, 17 Jul 2002 23:52:11 -0700 (PDT) >> From: Steven Edwards <ste...@ya...> >> To: rea...@li... >> Subject: [ros-kernel] newsgroup >> Reply-To: rea...@li... >> >> I forgot to add that you can help by responding in >> alt.config to help show support. >> >> Thanks >> Steven >> >> __________________________________________________ >> Do You Yahoo!? >> Yahoo! Autos - Get free new car price quotes >> http://autos.yahoo.com >> >> >> --__--__-- >> >> Message: 8 >> Date: Thu, 18 Jul 2002 09:35:53 +0000 >> From: David Welch <we...@cw...> >> To: rea...@li... >> Subject: Re: [ros-kernel] newsgroup >> Reply-To: rea...@li... >> >> On Wed, Jul 17, 2002 at 11:52:11PM -0700, Steven Edwards wrote: >> > I forgot to add that you can help by responding in >> > alt.config to help show support. >> > >> Do we really need a newsgroup? I don't see a lot of discussion of >> ReactOS on usenet and we could always use alt.os.development. >> >> >> --__--__-- >> >> Message: 9 >> Date: Thu, 18 Jul 2002 01:53:29 -0700 (PDT) >> From: Steven Edwards <ste...@ya...> >> Subject: Re: [ros-kernel] newsgroup >> To: rea...@li... >> Reply-To: rea...@li... >> >> I guess/hope not now. I forgot about the sig. juliet >> uses and that showed up a 1000 times and got flamed >> for it. Cancel the request as I have killed the thread >> and probly pissed everyone off anyway. =P What a bunch >> of nice people there are on usenet. >> >> Thanks >> Steven >> >> > Do we really need a newsgroup? I don't see a lot of >> > discussion of >> > ReactOS on usenet and we could always use >> > alt.os.development. >> >> >> __________________________________________________ >> Do You Yahoo!? >> Yahoo! Autos - Get free new car price quotes >> http://autos.yahoo.com >> >> >> --__--__-- >> >> Message: 10 >> From: "Eric Kohl" <ek...@rz...> >> To: <rea...@li...> >> Subject: Re: [ros-kernel] finally got good stack trace... >> Date: Thu, 18 Jul 2002 13:04:03 +0200 >> Reply-To: rea...@li... >> >> "Royce Mitchell III" <ro...@ev...> wrote: >> >> > I put a bunch of DbgPrint's all over that function last night, and >> didn't >> > see any of them on-screen... >> >> Please try a clean rebuild of the current CVS tree. David fixed some >> severe >> bugs and I got my 9 year old Seagate ST3144A (130 MB) running which >> reported >> 576 byte sectors. ;-) >> >> Eric >> >> >> >> --__--__-- >> >> Message: 11 >> Date: Thu, 18 Jul 2002 08:44:08 -0600 (Central Standard Time) >> From: Royce Mitchell III <ro...@ev...> >> To: rea...@li... >> Subject: Re: [ros-kernel] finally got good stack trace... >> Reply-To: rea...@li... >> >> I can't wait to try! >> >> /me rubbing hands with glee >> >> :) >> >> Royce3 >> >> > >> >Subject: Re: [ros-kernel] finally got good stack trace... >> > From: "Eric Kohl" <ek...@rz...> >> > Date: Thu, 18 Jul 2002 13:04:03 +0200 >> > To: <rea...@li...> >> > >> >"Royce Mitchell III" <ro...@ev...> wrote: >> > >> >> I put a bunch of DbgPrint's all over that function last night, and >> didn't >> >> see any of them on-screen... >> > >> >Please try a clean rebuild of the current CVS tree. David fixed some >> severe >> >bugs and I got my 9 year old Seagate ST3144A (130 MB) running which >> reported >> >576 byte sectors. ;-) >> > >> >Eric >> > >> > >> > >> >------------------------------------------------------- >> >This sf.net email is sponsored by:ThinkGeek >> >Welcome to geek heaven. >> >http://thinkgeek.com/sf >> >_______________________________________________ >> >reactos-kernel mailing list >> >rea...@li... >> >https://lists.sourceforge.net/lists/listinfo/reactos-kernel >> >> >> >> --__--__-- >> >> Message: 12 >> From: "Nick Date" <nic...@ya...> >> To: <rea...@li...> >> Subject: Re: [ros-kernel] The Explorer replacement we need. >> Date: Thu, 18 Jul 2002 17:28:43 +0100 >> Reply-To: rea...@li... >> >> Hiya. >> >> Sorry to step in after being away for so long (my life's up in the >> air at >> the moment to say the least). >> >> ----- Original Message ----- >> From: "KJK::Hyperion" <no...@li...> >> To: <rea...@li...> >> Sent: Wednesday, July 17, 2002 10:04 PM >> Subject: Re: [ros-kernel] The Explorer replacement we need. >> >> >> > At 20.25 17/07/2002, you wrote: >> >> > >Dont get me wrong I am not oposed to a project to rewrite >> explorer.exe. >> >> > and I'm not supporting such a project :-) Explorer isn't exactly >> the best >> > desktop around, it's Shell32 that matters >> >> [snip] >> >> You're right of course, but I think it would be nice to have a shell >> with a >> windoze-a-like feel to it. End users hate change of any sort and a >> familiar(ish) interface would probably stop them having a heart >> attack, or >> mental breakdown or whatever. ;-) >> >> Hi to everyone and sorry I'm not active in the message lists at the >> moment. >> I've got a new job starting on monday (warehouse work at a plumbing >> merchants) so things should start to pick up and I'll have more free >> time to >> keep up with the project. >> >> Best regards. >> >> Nick. >> >> -- >> Nick Date >> Bath, England, UK >> >> >> __________________________________________________ >> Do You Yahoo!? >> Everything you'll ever need on one web page >> from News and Sport to Email and Music Charts >> http://uk.my.yahoo.comm >> >> >> --__--__-- >> >> Message: 13 >> From: =?iso-8859-2?Q?H=E1morszky_Bal=E1zs?= <ba...@cr...> >> To: rea...@li... >> Subject: Re: [ros-kernel] The Explorer replacement we need. >> Date: Thu, 18 Jul 2002 20:11:53 +0200 >> Reply-To: rea...@li... >> >> >> Take two look: >> http://www.geoshellx.com/userguide.asp?doc=desktop.inc >> http://www.geoshellx.com/plugins/r48/geoDeskInstaller_1_0.exe >> >> >> >> >> >> --__--__-- >> >> _______________________________________________ >> reactos-kernel mailing list >> rea...@li... >> https://lists.sourceforge.net/lists/listinfo/reactos-kernel >> >> >> End of reactos-kernel Digest > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: KJK::Hyperion <no...@li...> - 2002-07-20 18:46:18
|
At 05.53 20/07/2002, Royce Mitchell III wrote: >Here's an impartial feature/non-feature list for an explorer clone: I'm keeping a list. If anyone wants to contribute theirs, go on >* keep in-situ start menu editing and right-click for items. Maybe also give a title bar to submenus, to let them be "teared" away and remain on-screen >* remove "web view" yeah! this was a big mistake >* everything can be customized, and should be easy to do so ( no editing >text files - that's a Linux thing ) right! I'm glad I'm not the only one to think this. ReactOS is a Windows and should look and feel like one >* xp-like user management ( ms finally got that right, if xp wasn't such a >flop ) what do you mean? >* extension hiding should *not* be default for power users. >* file hiding should *not* be default for power users. well said. Implementing this will also require multiple skeleton/template profiles - something that Windows doesn't have >* There should *never* be any reason for the OS to open a file unless the >user has performed some action on the file, or on a program that uses the >file. ( This will eliminate some of the nastier security holes explorer >has been plagued by ). this sounds a bit generic... >* file associations could work MUCH better. It's always a pain setting up >my .c, .h, .cpp, .hpp, etc associations. any idea about how to do it? I have several, but they would break existing programs |
|
From: Royce M. I. <ro...@ev...> - 2002-07-20 22:35:34
|
> >* keep in-situ start menu editing > > and right-click for items. Maybe also give a title bar to submenus, to let > them be "teared" away and remain on-screen > Can the be a compile option. It's sounds rather expensive code-wise, and I personally wouldn't have a use for it.... I think :) > >* xp-like user management ( ms finally got that right, if xp wasn't such a > >flop ) > > what do you mean? I take it you haven't seen Windows XP then. Well, in a nutshell, it works like this ( by default ): At login you are presented with a list of users, and each user's icon ( obviously unnecessary ). If a user is already logged in ( wouldn't happen on boot-up obviously ) then it shows that user as being logged in. This isn't really why I say it's better, but I can't think of a better way to do this. The better part is this: User's can log off without having to shut down the applications they are running. I realize this is a tall order, and probably would be difficult to pull off, but it is one of the few features I actually like in XP. Now that I think about it, there's one more thing in XP we should bring to the table: XP's compatibility mode. You can tell an application it's running under 98, ME, NT4, or 2000, and you can have the OS automatically change the resolution and color depth when running the application. These options are accessed under a new tab in the file's properties dialog. > > >* extension hiding should *not* be default for power users. > >* file hiding should *not* be default for power users. > > well said. Implementing this will also require multiple skeleton/template > profiles - something that Windows doesn't have Yeah :( You have to break some new ground when building a better mouse trap, huh? > >* There should *never* be any reason for the OS to open a file unless the > >user has performed some action on the file, or on a program that uses the > >file. ( This will eliminate some of the nastier security holes explorer > >has been plagued by ). > > this sounds a bit generic... You seen nimda? Just hovering your mouse over a file ( you didn't even have to click it ), and the virus would copy itself. > >* file associations could work MUCH better. It's always a pain setting up > >my .c, .h, .cpp, .hpp, etc associations. > > any idea about how to do it? I have several, but they would break existing > programs Obviously we can't change HKCR. The best thing would be to create a solution that would work for all windows operating systems. I have a .REG file for my associations, but it needs tweaking depending on where I install VC and where I install SciTE. A major major problem I have with the file associations dialog in explorer is that the "Set Default Action" is completely broken. I think that probably the only solution would be to write a simple utility that reads a REG file, and looks for common paths, and gives you an option to modify them. Or perhaps reads a REG file, and looks for environment-like macros ( %vcpath% ), and prompts you to enter what they should be, and if multiple actions on a file extension, prompts you for which is default ( unless someone can tell me if there's a registry entry for which one is default - I haven't been able to find such a beast. From what I can tell, the first action created is always default ). |
|
From: Diego I. <ias...@ac...> - 2002-07-23 16:52:03
|
=E1=E9=E5=ED =F8=E0=F9=E5=EF, 21 =E1=E9=E5=EC=E9 2002, 01:31, Royce Mitch= ell III =EB=FA=E1: > At login you are presented with a list of users, and each user's icon ( > obviously unnecessary ). If a user is already logged in ( wouldn't happ= en > on boot-up obviously ) then it shows that user as being logged in. This > isn't really why I say it's better, but I can't think of a better way t= o do > this. The better part is this: User's can log off without having to shu= t > down the applications they are running. I realize this is a tall order,= and > probably would be difficult to pull off, but it is one of the few featu= res > I actually like in XP. do you mean switch user? note that this user is still logged on. OTOH, a program that wil run for several users (sharing memory && recourc= es) =20 wil be cool. Think of cmd.exe, windows commander, ICQ and what ever. I wo= uld=20 like to share this programs betwen logged users. - diego --=20 Let sleeping dogs lie. -- Charles Dickens |
|
From: Royce M. I. <ro...@ev...> - 2002-07-22 19:32:00
|
I considered this possibility, but I don't see how they would take up more
room than the code. If you don't cache the data, then you have to at least
put it on the stack or in a register. In order to get it there, you probably
have to place a function call. There's a 5-byte instruction already. On top
of that, we probably have to pass parameters to that function call. Let's
say a pointer to the parameter name, or an identifier at least. We're up to
9 bytes now. So, at a minimum, if we don't cache settings, we need at least
9 bytes for every point of code where we wish to pull them in. OTOH, a mov
eax, [var] is 5 bytes I think, 6 at most.
If I'm mistaken, please show me the error of my ways :)
It seems to me, if each setting is only accessed once, we save 4 bytes per
variable for each one we cache. If a particular setting is accessed more
often, then the savings only increase.
I do realize there are more storage considerations, but I think they are
moot, especially as a setting's usage increases.
For example, let's say each setting is accessed via a 16-bit identifier ( to
save space ). Let's also say there's a single function for loading
parameters, and it only needs this 16-bit identifier to return the requested
setting via EAX: There is only the size of the function for static storage
requirements for all settings, and no static storage requirements for
individual settings. Accessing each settings results in a 8-byte pair of op
codes:
MOV AX, id ( 3 bytes )
CALL func ( 5 bytes )
If we have 100 settings each accessed 100 times, this results in 80kb worth
of code for utilizing the settings.
OTOH, let's say we cache all settings. The same single function for loading
parameters exists, so the storage space for this function is not necessary
for this comparison. However, a new function exists which must be called on
application startup which will cache all the settings ( perhaps in a
background thread ). This function must call the loading function once for
each of the 100 settings. Each setting is loaded like this:
MOV AX, id ( 3 bytes )
CALL func ( 5 bytes )
MOV [var], EAX ( 5 bytes )
That results in an appx 1300 byte function. Now, for each setting to be
accessed, we must do this:
MOV EAX, [var] ( 5 bytes )
So, if each setting is accessed a 100 times, that results in 50kb worth of
code to access the settings. Also, the program's memory footprint is
increased by sizeof(var) * 100 = 400 bytes.
Our total impact on memory comes to this: 1300 + 50000 + 400 = 51700.
So, my attempt to compare the two comes up with this:
non-cacheing: 80k
cacheing: 52k
I'm obviously not addressing performance issues, but I can't possibly see
how (even) frequent cpu cache-misses could be slower than accessing the
registry constantly.
Royce3
----- Original Message -----
From: "Casper Hornstrup" <ch...@us...>
To: <rea...@li...>
Sent: Saturday, July 20, 2002 10:05 AM
Subject: Re: [ros-kernel] Re: ROS gui
lør, 2002-07-20 kl. 16:18 skrev Royce Mitchell III:
>
> ----- Original Message -----
> > Looking up registry keys and values is not an expensive task in terms of
> > time consumption, but keeping *all* settings in memory is expensive in
> terms
> > of memory consumption. This also obsoletes the concept of monitoring
> changes
> > to the registry, at least in most cases.
>
> Also, I forget to mention that most settings will take up less space than
> the code to call the registry and reload it.
Maybe they do in your average free text editor application, but not in
your average full blown comercial application with several thousands of
settings.
Casper
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
reactos-kernel mailing list
rea...@li...
https://lists.sourceforge.net/lists/listinfo/reactos-kernel
|
|
From: Jarmo M. <ja...@mu...> - 2002-07-22 20:33:34
|
Hmm, others seem to have different way of programming than I have.
Lets say that I have few settings. I would write a class which has
interfaces for getting and setting values. Method is invisible to
the caller. It might use INI files or registry. It might read
settings from ini/reg every time it is called or it might cache
it.
In application class I'd have
private:
Settings settings;
In code I'd have
LANGID langID = settings.GetCurrentLanguageID();
So, from the caller's point of view there is no difference is it
cached or not. If it is cached, it might work a bit faster, if
used very frequently. If it is not cached, it would be a bit
slower, but it depends on what you're reading/writing and where
from/to.
Now to the code:
Non-cached version:
LANGID Settings::GetCurrentLanguageID()
{
DWORD value;
if ( QueryValue( TEXT("LanguageID"), value ) )
return LANGID(value);
return GetDefaultLanguageID();
}
Cached version:
class Settings
{
...
private:
LANGID currentLanguageID;
};
Settings::Settings()
{
DWORD value;
if ( QueryValue( TEXT("LanguageID"), value ) )
currentLanguageID = LANGID(value);
else
currentLanguageID = GetDefaultLanguageID();
}
// this is so short that it is sensible to write a inline function
in .h
inline LANGID Settings::GetCurrentLanguageID() const
{
return currentLanguageID;
}
Cached version with delayed query:
class Settings
{
...
private:
LANGID currentLanguageID;
};
Settings::Settings()
: currentLanguageID( 0 )
{
}
LANGID Settings::GetCurrentLanguageID()
{
if ( currentLanguageID == 0 )
{
DWORD value;
if ( QueryValue( TEXT("LanguageID"), value ) )
currentLanguageID = LANGID(value);
else
currentLanguageID = GetDefaultLanguageID();
}
return currentLanguageID;
}
Of course QueryValue is a function which queries DWORD value from
registry of from INI file. RegistryKey is opened in the first call
and the function itself knows where to read from.
Which one is fastest? Which one takes less memory? I actually
don't care, because it is dependent on frequent of usage. You just
cache some, if you feel that it's necessary.
JMu
----- Original Message -----
From: "Royce Mitchell III" <ro...@ev...>
To: <rea...@li...>
Sent: Monday, July 22, 2002 10:27 PM
Subject: Re: [ros-kernel] Re: ROS gui
> I considered this possibility, but I don't see how they would
take up more
> room than the code. If you don't cache the data, then you have
to at least
> put it on the stack or in a register. In order to get it there,
you probably
> have to place a function call. There's a 5-byte instruction
already. On top
> of that, we probably have to pass parameters to that function
call. Let's
> say a pointer to the parameter name, or an identifier at least.
We're up to
> 9 bytes now. So, at a minimum, if we don't cache settings, we
need at least
> 9 bytes for every point of code where we wish to pull them in.
OTOH, a mov
> eax, [var] is 5 bytes I think, 6 at most.
>
> If I'm mistaken, please show me the error of my ways :)
>
> It seems to me, if each setting is only accessed once, we save 4
bytes per
> variable for each one we cache. If a particular setting is
accessed more
> often, then the savings only increase.
>
> I do realize there are more storage considerations, but I think
they are
> moot, especially as a setting's usage increases.
>
> For example, let's say each setting is accessed via a 16-bit
identifier ( to
> save space ). Let's also say there's a single function for
loading
> parameters, and it only needs this 16-bit identifier to return
the requested
> setting via EAX: There is only the size of the function for
static storage
> requirements for all settings, and no static storage
requirements for
> individual settings. Accessing each settings results in a 8-byte
pair of op
> codes:
> MOV AX, id ( 3 bytes )
> CALL func ( 5 bytes )
> If we have 100 settings each accessed 100 times, this results in
80kb worth
> of code for utilizing the settings.
>
> OTOH, let's say we cache all settings. The same single function
for loading
> parameters exists, so the storage space for this function is not
necessary
> for this comparison. However, a new function exists which must
be called on
> application startup which will cache all the settings ( perhaps
in a
> background thread ). This function must call the loading
function once for
> each of the 100 settings. Each setting is loaded like this:
> MOV AX, id ( 3 bytes )
> CALL func ( 5 bytes )
> MOV [var], EAX ( 5 bytes )
> That results in an appx 1300 byte function. Now, for each
setting to be
> accessed, we must do this:
> MOV EAX, [var] ( 5 bytes )
> So, if each setting is accessed a 100 times, that results in
50kb worth of
> code to access the settings. Also, the program's memory
footprint is
> increased by sizeof(var) * 100 = 400 bytes.
> Our total impact on memory comes to this: 1300 + 50000 + 400 =
51700.
>
> So, my attempt to compare the two comes up with this:
>
> non-cacheing: 80k
> cacheing: 52k
>
> I'm obviously not addressing performance issues, but I can't
possibly see
> how (even) frequent cpu cache-misses could be slower than
accessing the
> registry constantly.
>
> Royce3
>
> ----- Original Message -----
> From: "Casper Hornstrup" <ch...@us...>
> To: <rea...@li...>
> Sent: Saturday, July 20, 2002 10:05 AM
> Subject: Re: [ros-kernel] Re: ROS gui
>
>
> lør, 2002-07-20 kl. 16:18 skrev Royce Mitchell III:
> >
> > ----- Original Message -----
> > > Looking up registry keys and values is not an expensive task
in terms of
> > > time consumption, but keeping *all* settings in memory is
expensive in
> > terms
> > > of memory consumption. This also obsoletes the concept of
monitoring
> > changes
> > > to the registry, at least in most cases.
> >
> > Also, I forget to mention that most settings will take up less
space than
> > the code to call the registry and reload it.
>
> Maybe they do in your average free text editor application, but
not in
> your average full blown comercial application with several
thousands of
> settings.
>
> Casper
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>
|
|
From: Robert K. <ro...@ko...> - 2002-07-22 20:35:02
|
Don't go into peanuts and don't count peas. If you wanna get efficient programs, then use Registry as you want and use variables as you want. As long as you don't use MFC (or th. like that) you'll save the most memory and CPU-time. Royce Mitchell III schrieb: >I considered this possibility, but I don't see how they would take up more >room than the code. If you don't cache the data, then you have to at least >put it on the stack or in a register. In order to get it there, you probably >have to place a function call. There's a 5-byte instruction already. On top >of that, we probably have to pass parameters to that function call. Let's >say a pointer to the parameter name, or an identifier at least. We're up to >9 bytes now. So, at a minimum, if we don't cache settings, we need at least >9 bytes for every point of code where we wish to pull them in. OTOH, a mov >eax, [var] is 5 bytes I think, 6 at most. > >If I'm mistaken, please show me the error of my ways :) > >It seems to me, if each setting is only accessed once, we save 4 bytes per >variable for each one we cache. If a particular setting is accessed more >often, then the savings only increase. > >I do realize there are more storage considerations, but I think they are >moot, especially as a setting's usage increases. > >For example, let's say each setting is accessed via a 16-bit identifier ( to >save space ). Let's also say there's a single function for loading >parameters, and it only needs this 16-bit identifier to return the requested >setting via EAX: There is only the size of the function for static storage >requirements for all settings, and no static storage requirements for >individual settings. Accessing each settings results in a 8-byte pair of op >codes: > MOV AX, id ( 3 bytes ) > CALL func ( 5 bytes ) >If we have 100 settings each accessed 100 times, this results in 80kb worth >of code for utilizing the settings. > >OTOH, let's say we cache all settings. The same single function for loading >parameters exists, so the storage space for this function is not necessary >for this comparison. However, a new function exists which must be called on >application startup which will cache all the settings ( perhaps in a >background thread ). This function must call the loading function once for >each of the 100 settings. Each setting is loaded like this: > MOV AX, id ( 3 bytes ) > CALL func ( 5 bytes ) > MOV [var], EAX ( 5 bytes ) >That results in an appx 1300 byte function. Now, for each setting to be >accessed, we must do this: > MOV EAX, [var] ( 5 bytes ) >So, if each setting is accessed a 100 times, that results in 50kb worth of >code to access the settings. Also, the program's memory footprint is >increased by sizeof(var) * 100 = 400 bytes. >Our total impact on memory comes to this: 1300 + 50000 + 400 = 51700. > >So, my attempt to compare the two comes up with this: > >non-cacheing: 80k >cacheing: 52k > >I'm obviously not addressing performance issues, but I can't possibly see >how (even) frequent cpu cache-misses could be slower than accessing the >registry constantly. > >Royce3 > >----- Original Message ----- >From: "Casper Hornstrup" <ch...@us...> >To: <rea...@li...> >Sent: Saturday, July 20, 2002 10:05 AM >Subject: Re: [ros-kernel] Re: ROS gui > > >lør, 2002-07-20 kl. 16:18 skrev Royce Mitchell III: > > >>----- Original Message ----- >> >> >>>Looking up registry keys and values is not an expensive task in terms of >>>time consumption, but keeping *all* settings in memory is expensive in >>> >>> >>terms >> >> >>>of memory consumption. This also obsoletes the concept of monitoring >>> >>> >>changes >> >> >>>to the registry, at least in most cases. >>> >>> >>Also, I forget to mention that most settings will take up less space than >>the code to call the registry and reload it. >> >> > >Maybe they do in your average free text editor application, but not in >your average full blown comercial application with several thousands of >settings. > >Casper > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > |
|
From: Diego I. <ias...@ac...> - 2002-07-23 16:52:03
|
=E1=E9=E5=ED =F9=F0=E9, 22 =E1=E9=E5=EC=E9 2002, 23:37, Robert K. =EB=FA=E1= : > Don't go into peanuts and don't count peas. > If you wanna get efficient programs, then use Registry as you want and > use variables as you > want. As long as you don't use MFC (or th. like that) you'll save the > most memory and CPU-time. can you recommed a nice gui that works with mingw then? or even with the=20 command line tools from borland?=20 - diego --=20 You are only young once, but you can stay immature indefinitely. |
|
From: KJK::Hyperion <no...@li...> - 2002-08-05 22:20:57
|
At 18.23 23/07/2002, you wrote: >=E1=E9=E5=ED =F9=F0=E9, 22 =E1=E9=E5=EC=E9 2002, 23:37, Robert K. =EB=FA=E1= : > > Don't go into peanuts and don't count peas. > > If you wanna get efficient programs, then use Registry as you want and > > use variables as you > > want. As long as you don't use MFC (or th. like that) you'll save the > > most memory and CPU-time. >can you recommed a nice gui that works with mingw then? or even with the=20 >command line tools from borland? wxWindows. But produces even larger executables than MFC |
|
From: Koert v. d. V. <ko...@ic...> - 2002-07-23 18:47:54
|
> do you mean switch user? note that this user is still logged on. > OTOH, a program that wil run for several users (sharing memory && recources) > wil be cool. Think of cmd.exe, windows commander, ICQ and what ever. I would > like to share this programs betwen logged users. A potential pittfall for such a structure is user permissions. Consider an admin and a simple user sharing notepad (ridiculous, I know...) What happens if the admin tries to open a severly protected file, such as kernel32.dll, and what happens when the user tries to open it? The program would have to behave differently for each of these situations, so either the uid an gid of the proces should be changed, or the program should handle this itself. In the latter, part of the code has to run as user 'System' (or, at your option, root), which imposes severe security risks, as a simple buffer overflow would enable a local (or perhaps even remote) user to gain all permissions. Anyway, I guess that would be a program-design issue, not an os-issue, so perhaps it is not really relevant to this list. |
|
From: Joachim B. <jmb...@gm...> - 2002-07-23 20:13:07
|
"Koert van der Veer" <ko...@ic...> writes: >> do you mean switch user? note that this user is still logged on. >> OTOH, a program that wil run for several users (sharing memory && >> recources) wil be cool. Think of cmd.exe, windows commander, ICQ >> and what ever. I would like to share this programs betwen logged >> users. > > A potential pittfall for such a structure is user permissions. Consider an > admin and a simple user sharing notepad (ridiculous, I know...) What happens > if the admin tries to open a severly protected file, such as kernel32.dll, > and what happens when the user tries to open it? The program would have to > behave differently for each of these situations, so either the uid an gid of > the proces should be changed, or the program should handle this itself. In > the latter, part of the code has to run as user 'System' (or, at your > option, root), which imposes severe security risks, as a simple buffer > overflow would enable a local (or perhaps even remote) user to gain all > permissions. In the world I come from "all" read-only parts of the program, such as the actual executable code (in the usual case, anyway), gets only loaded once and, depending on OS designed, used more or less directly out of the buffer cache pages. As this data is read-only sharing it between instances is indistinguishable from each instance having its own copy. All data which makes the program relate to its environment (data and stack, which roughly correspond to the "variables" in the source code) is allocated per instance (no matter whether these instances span different users or not). Especially the process control structure, which also "contains" the security context, is allocated per instance. Perhaps this can clarify how such a structure might work; especially that it does not necessarily require consent of the applications. I honestly don't know how much of that MS really implements. Btw, one of the frustrating points in using windows for me is that most programs have ill-defined notions of what should be "read-only", imposing severe limitations to the scheme above. Try to do just about anything with a read-only %SystemRoot% or HKLM... (pet peevee) So long, Joe P.S. I didn't forget about the "Wishlist for Windows by a Unix user", finding the time to do it is the harder part... -- "I use emacs, which might be thought of as a thermonuclear word processor." -- Neal Stephenson, "In the beginning... was the command line" |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X