reactos-kernel Mailing List for ReactOS (Page 5)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Can anyone stop this spammers? Why can't we block them?

bye

"James Marjie" <jid...@sa...> wrote:

> Has anyone else gotten like three or so junk emails sent to the
> ros...@re... address?

This mailing list does not exist any more. It is ordinary spam using a faked
from-address. The spammer is not subscribed to the mailing list.

Ignore it and delete it!

Eric

"Robert K." <ro...@ko...> wrote:

> Congratulations. Let's hope this is the only thing that has to be fixed
> in order to run
> MSVC compilend pgms.   It's at least an impotand step.

No, it seems there are more bugs ahead!
I changed the code in NtMapViewOfSection() to make all parts of a mapped
image section writable. The simple 'hello world!' example crashed upon
initialization. This is propably due to missing or buggy SEH-support.

> Whose mistake is it ?     MSVC, Mingw, NT or ROS?
It is not a mistake! MSVC executables and MinGW executables have a slightly
different layout. That's all. Of course, M$ could use this to get rid of
'evil, criminal, cancerous <insert more buzzwords here> open source
applications' by adding some checks to the loader.

Eric

Congratulations. Let's hope this is the only thing that has to be fixed 
in order to run
MSVC compilend pgms.   It's at least an impotand step.

Whose mistake is it ?     MSVC, Mingw, NT or ROS?

Eric Kohl schrieb:

>Hi!
>
>I just found out why application compiled with MSVC++ don't run on ReactOS.
>
>These apps have a slighly different layout compared to apps compiled with
>MinGW. MSVC++ stores the IAT (Import Address Table) inside of the .rdata
>section, MinGW stores the IAT inside of the .data section. Now the problem
>is that the .rdata setion is read-only. To fix-up the IAT of an application
>the offsets stored in the IAT must be overwritten by the real import
>addresses. Obviously this wont work if the IAT is inside of a read-only
>section.
>
>To fix this bug I added calls to NtProtectVirtualMemory() to the fixup
>routine to change the IAT's protection to read-write before it is modified
>and reset its protection after the fixup is done.
>
>When I had a look at NtProtectVirtualMemory() I saw that its core
>functionality is disabled. What's wrong?
>
>
>Regards,
>Eric
>
>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
>  
>

"Steven Edwards" <ste...@ya...> wrote:

> Take a look at this on google. Search for "equitable estoppel". To sum it
up, if they knew or know
> that we are using some of there IP. The only thing they really have
patented are gdi related
> things and if they do nothing to stop us then the patent will be rendered
null. I think that as
> the wine project has managed to not get sued to date then we should be ok.

Don't you confuse patents and trademarks?
In Germany a trademark is rendered null and void if the owner of that
trademark doesn't enforce his ownership. A trademark also expires if the
owner doesn't use it within five years after the registration.

Eric

yess i've got them

On Wed, 24 Jul 2002 03:05:31 -0700
James Marjie <jid...@sa...> wrote:

> Has anyone else gotten like three or so junk emails sent to the 
> ros...@re... address?
> -- 
> James Marjie

Yup, All three in chinese or japanese. 

----- Original Message ----- 
From: "James Marjie" <jid...@sa...>
To: <rea...@li...>
Sent: Wednesday, July 24, 2002 12:05 PM
Subject: [ros-kernel] Spam?

Has anyone else gotten like three or so junk emails sent to the 
ros...@re... address?
-- 
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

Has anyone else gotten like three or so junk emails sent to the=20
ros...@re... address?
--=20
James Marjie

Take a look at this on google. Search for "equitable estoppel". To sum it up, if they knew or know
that we are using some of there IP. The only thing they really have patented are gdi related
things and if they do nothing to stop us then the patent will be rendered null. I think that as
the wine project has managed to not get sued to date then we should be ok.

Thanks
Steven

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

This rocks dude. If you want me to help with testing/debugging this I will reinstall MS_VC and
compile some simple applications once you figure out more of whats going on. 

Thanks
Steven

> I just found out why application compiled with MSVC++ don't run on ReactOS.
> These apps have a slighly different layout compared to apps compiled with
> MinGW. MSVC++ stores the IAT (Import Address Table) inside of the .rdata
> section, MinGW stores the IAT inside of the .data section. Now the problem
> is that the .rdata setion is read-only. To fix-up the IAT of an application
> the offsets stored in the IAT must be overwritten by the real import
> addresses. Obviously this wont work if the IAT is inside of a read-only
> section.
> 
> To fix this bug I added calls to NtProtectVirtualMemory() to the fixup
> routine to change the IAT's protection to read-write before it is modified
> and reset its protection after the fixup is done.
> 
> When I had a look at NtProtectVirtualMemory() I saw that its core
> functionality is disabled. What's wrong?

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

"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"

> 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.

=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.

=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

"Ian McLean" <ian...@op...> wrote:

> Hi Guys,
>
> Latest CVS download fails during the build of GDI32.

The missing file has already been checked in. Please update your local
source tree.

Regards,
Eric

Hi!

I just found out why application compiled with MSVC++ don't run on ReactOS.

These apps have a slighly different layout compared to apps compiled with
MinGW. MSVC++ stores the IAT (Import Address Table) inside of the .rdata
section, MinGW stores the IAT inside of the .data section. Now the problem
is that the .rdata setion is read-only. To fix-up the IAT of an application
the offsets stored in the IAT must be overwritten by the real import
addresses. Obviously this wont work if the IAT is inside of a read-only
section.

To fix this bug I added calls to NtProtectVirtualMemory() to the fixup
routine to change the IAT's protection to read-write before it is modified
and reset its protection after the fixup is done.

When I had a look at NtProtectVirtualMemory() I saw that its core
functionality is disabled. What's wrong?

Regards,
Eric

Eric

Hi Guys,

Latest CVS download fails during the build of GDI32.

Details:-

make -C lib/gdi32
make[1]: *** No rule to make target `objects/region.o', needed by `gdi32.o'.
St
op.
make[1]: Entering directory
`D:/Development/PROJECTS/REACTOS/source/reactos/lib/
gdi32'
make[1]: Leaving directory
`D:/Development/PROJECTS/REACTOS/source/reactos/lib/g
di32'
make: *** [gdi32] Error 2

Rgs
Ian.

I was wondering will my message get any feedback. At least one. My
title is "ATK suunnittelija" in Finnish (in English it would mean
"Software Designer"). Nowadays I am keen to more designing than
programming. I'd like others do the programming. At least web UI
things because it's still a mess (VBScript). I hope .NET would be
more OO. I do like programming too, but designing it first a bit
better than before.

OT: I have noticed that many times people (even English speaking)
write "that" when they should write "than". I don't know the
reason. In upper paragraph I wrote "that" two times and corrected
them to "than". Why I wrote "that"???

I have an impression that many ReactOS developers don't design so
much. Have I got it wrong? Does anyone design using UML? Like
drawing class and activity diagrams for example. It would be nice
if ReactOS site would have few UML dialgrams.

Now to the answer. I meant "developer". I wrote "user" instead. I
have made this mistake before.

Usability tests come later when the program is running. Before
that you need UR (usability requirements). If they are very
defined the program could be usable. "Could be" because URs might
be not that good. Think before you do is a good advice.

I visited quickly at http://www.joelonsoftware.com/ and noticed
that they/he have/has very similar bug tracking system than we
have made. We have more fields to fill/to follow. At first it was
built with Centure/SQLWindows (still in use) and now we have a web
based version.

JMu

----- Original Message -----
From: "KJK::Hyperion" <no...@li...>
To: <rea...@li...>
Sent: Sunday, July 21, 2002 12:58 AM
Subject: Re: [ros-kernel] FURPS

> At 08.35 20/07/2002, Jarmo Muukka wrote:
> >I thought that it would be cool idea to have a web page where
users would
> >have a possibility to see and add requirements.
>
> mmmh. I'm not sure. Some good old usability tests would be
better. You can
> look at what the users expect the software to do, which is
important.
> Nobody should ever be forced to face a bug report or feature
request form
>
> >These could be possible to see/add per module. It should be
controlled
> >someway.
>
> can you say "moderation"? last time I saw WinE's list of
supported
> applications, it was a chaotic mess: automatization is cool and
stuff, but
> moderation is sometimes necessary. Better yet: find some
volunteers ("on
> your marks...") for a help desk ("RUN!!!"), that will be the
only people to
> have direct contact with the users, and shield them from the
beautiful hell
> of mailing lists, bug report forms, and all those things that
nobody in
> their right mind would like to be subject to
>
> [...]
> >I hope that you got the point. When you read this you might not
like
> >something, or think that it's too complicated, or there is
something
> >missing, or req is not needed, or it can be implemented later,
etc.
>
> I suggest you (all of you) to have a look at Joel Spolsky's
weblog:
>
> <http://www.joelonsoftware.com/>
>
> He speaks of software management mainly, but also of user
interfaces. He
> has a lot of common sense and humor. A good read. Too bad he
doesn't update
> very often
>
> >I feel that adding detailed requirements before we write a line
of code
> >will pay it back.
>
> definitely agree
>
> >By the way, the reqs are so general that there are no UI
specific things.
>
> This doesn't mean that the UI doesn't require a spec on its own,
of course
>
> >Was this interesting or not?
>
> if not else, at least someone has had the guts to bring this out
>
>
>
> -------------------------------------------------------
> 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
>

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
>  
>

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
>

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

Fixed. 

--- Brian Palmer <br...@sg...> wrote:
> It looks like a couple of the bitmaps in rosapps\hcalc are garbled. I'll
> bet they just need to be committed in binary mode instead of text. Does
> anyone have an original copy of them?

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

l=F8r, 2002-07-20 kl. 16:18 skrev Royce Mitchell III:
>=20
> ----- Original Message -----
> > Looking up registry keys and values is not an expensive task in terms o=
f
> > 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.
>=20
> 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

It looks like a couple of the bitmaps in rosapps\hcalc are garbled. I'll
bet they just need to be committed in binary mode instead of text. Does
anyone have an original copy of them?

Brian

From what I have seen they are going for a system that acts like windows but isnt windows. I think
they are going to be putting together a linux distro that acts like Windows sort of like Lindows.
My guess is they will ship Open/StarOffice with the default file formats being Office2K. See the
slashdot threads for more info.

Steven

--- Jason Filby <jas...@ya...> wrote:
> Since these guys may not have the source, I think I'll try and
> contact them. Just to find out what they're up to and if they do have
> any source that would scare us off.
> 
> - Jason

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

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

reactos-kernel Mailing List for ReactOS (Page 5)

An operating system based on the best Windows NT design principles

reactos-kernel