Thanks for all of your help folks ...
well I have a work around solution. The problem was really what to
about a dynamic runtime array - size previously unknown and yes you
were right pointer structures are the key;
In this case I allow the emsLinestart to allocate tthe memory as an
untyped pointer.
Then I create a pointer to
wrec =record
l,h:word
end;
Now there are two choices I can normalise the pointer by adding a 4
byte offset to it by calling a pascal version of far pointer (this
corrects for crossing segment boundaries)
eg p := dosalloc(emsLinestart;4*lines);
for i := 0 to lines do {i've simplified this from
above}
begin
p := farPtr(p,sizeOf(wrec)); {normalise ptr and add a long to
it}
wrec := p;
wrec^.l := offset; { i've ignored th
****ft ,its just a demo}
wrec^.h := page;
offset := offset + bytes
etc ....
end;
when you finished simply dosFree(p);
(Im using these direcxt dos routines so that I can get > 64k buffers}
or, if I'm not worried about crossing a segment boundary , quick n
dirty,( you wouldn't want use this when getting big chunks of memory )
I can simply cast untyped pointer p to a pchar, do some maths on it
and then recast back to p again , then apply wrec to it.
I've tried a little test program based on the above and I can fill and
display the contents of
this dynamic array no problem. Have a go its quite fun. I did some
further research and discovered that this is one of the fundamental
differences between C and pascal. C allows you to do 'dangerous
things' with pointers like above whereas pascal and nearly all other
languages don't, or make you jump through hoops to acheive the same
result. I have alot more respect fo C now and though I'm a dedicated
pascal person I can now see where the c programmers claim that its
often easier to low level stuff in C is coming from...
2. Pascal - thanks that answers my question.
3. Well you could argue that protected mode is an unnecssary
complication of linear flat addressing. Apple managed without it for
ever. They only went Intel because of the speed.
and then linux only partitions the OS into two. If the ultimate
progression of a protected OS is Vista, then god help us because it is
has taken the protection argument to such an absurdity that it is now
simply denial of service software. Program and resource mapping could
as easily be handled by software task management which is the function
of an OS anyway . I think that the future of OS's is now flat and
hardware unprotected. Especially with 64 bit addressing - we will soon
really no longer even have to worry about virtualisation.
4. Swag, thanks for the encouragement. I think I should post this as a
separate main topic on all of the comp.lang. pascal groups to see what
sort of feedback it generates. Yes it would be a lot of work and it
would probably need some volunteer help. One of the advantages of a
message board is that snippets could be discussed and rated for
inclusion in a swag bag by people who had specific interest or
knowlege of the subject.
Dos is not dead, its just DPMI32 and our lovely language of preference
doesn't sup****t it.
V pascal is quite good and so is the DPMI32 unit once you get hold of
it. A highly underated
language - a pity it's no longer developed. For reasons why dos
should'nt be allowed to die see 3 above. We now have a whole
generation of programmers who could'nt do anything with dos to save
their lives and can only program the windows api. The thing that's
worth saving about dos is not dos itself but because it shows how to
program at a fairly low level thus keeping the notion that there might
be one day be an alternative os to Mswin alive.(ie, something that
works, is cheap and costs 1 dollar so eveyone will buy it). I don't
count linux here because what ever you say and no matter how you wrap
it its too nerdy for the m***** - we need something new. (MacOs would
be nicer if it went no propriatary multi- platform and cheap hmm...
wasn't that the idea behind windows?)
Anyway Turbo & Bp is not just about dos its about techniques and ways
of doing things that are applicable to any language and I also don't
see why swag can't now be extended to Delphi, C++ and anyone else who
wants to play :)
Marco van de Voort wrote:
> On 2007-05-24, winston19842005@[EMAIL PROTECTED]
<winston19842005@[EMAIL PROTECTED]
>
wrote:
> >> > when it came to pointers. I would've thought it would be trival...
> >>
> >> Not define it as pointer of integer/word but as pointer to array of
> >> integer/word.
> >
> > That is what I was thinking. What I couldn't grok was how to determine
> > the size of the array at compile time given that the allocation size
> > could change.
>
> As large as possible. Since you don't really allocate it anyway.
>
> > Is this compiler dependent or is there a ****table way?
>
> This is fairly common for compiled versions, even of the non-Borland
kind. I
> don't know if this works with bytecode compilers.
>
> > The books I have are more introductory and give up just shy of this
> > material, ending about the point of linked-lists...
>
> If you want to see "real" code, have a look at the freepascal codebase
(even
> though it is 32/64-bit protected mode)
|
