I change subjects a little to address another issue that has bugged me for
a considerable amount of time.
As we go forward and switch our base implementation to be 32W, the
16 & 32A subsystems become devoid of semantics. They simply contain code
that does:
16 -> 32A
32A -> 32W
Now, all this code is at the moment scattered all over the
place. Initially, this made sense, but more and more it becomes a problem:
1. code clutter
2. harder to maintein
3. runtime inefficiency
I will try to explain, one by one, the above points:
1. code clutter
usually a Wine .c file contain a semantically meaningfull component of
the system. When one wants to look at that file, most of the time the
intent is to undertand its semantics/fix behavioural bugs, etc. While
going through the code, one is distracted by this blurbs of meaningless
code which does some boring transformations.
2. harder to maintein
due to the nature of this code, the type of mainteinance one performs on
them is different from normal code. In the 32W code (which has semantics),
one usually looks at a function to code/fix it. In the 16/32A part (the
one devoided of semantics), one usually audits all the code of certain
type. You usually solve problems of the form: "how do I convert X?". When
you find an answer, you want to apply the result everywhere where X is
converted. Because the code is scattered now, this sort of thing is a lot
harder to do.
3. runtime inefficiency
yes, we do have demand loading. But that is done with a certain
granularity, which means most likely that we end up loading the 16bit part
in memory for a 32bit only app.
Now, what I propose is that we separate these pieces of code out into a
16.c and a A.c file. That is, for a file x that has 16bit and/or 32A code,
we create two/one file(s) x16.c and/or x32A.c
Comments?
--
Dimi.
