*.DLL libraries
ZXNet echo conference «code.zx»
Press RESET immediately, All!
Newsgroups: fido7.zx.spectrum
From: Kirill Frolov
Subject: Re: Doors 2003! RE:inferno4_1.zip
References: <3121331872@p2.f827.n5030.z2.ftn> <1060789410@f19.n451.z2.ftn>
Organization: we put an end to alasm, zasm is the next generation!
Follow-To:
X-Comment-To: Oleg Golenkoff
User-Agent: [ZX]
X-FTN-PID: Lara Croft MED 5.0+ by KVA of E-mage
Press RESET immediately, Oleg Golenkoff!
On Wed, 13 Aug 03 14:43:30 +0400, Oleg Golenkoff wrote:
OG>>> can you make your own compiler? let it be slower, but
OG>>> in plain text.
KF>> For the spectrum? You will also need a text editor and files... in short
KF>> speaking, first you need some kind of OS.
OG> yeah! hence the moral, make an OS for your computer
OG> and write an editor - a compiler for it with the option
OG> recompilation for a specific other computer
Flag in hand... (for Microsoft this took ~15 years)
I'm thinking: it would be nice to have some common format for executable files
and/or libraries for all ZX*OS. There is a lot of system-independent code,
which can be used without modification, or with minimal effortboth in TR-DOS programs, and in Aqua-OS, and in other D2k and X-DOS, BeeOS...
Of course, you can always pick up the source, but the source may not be available,
for this you need a certain version of assembler that is incompatible with the one you are using
(such as ZASM and ALASM), dynamic
downloading code, nor sharing it among multiple programs.
What happens is that programs increase in size, despite the fact that they contain
almost the same code. And their support, in the case when parts are used
code from different people becomes simply impossible - for example, if I
released a new version of the IDE driver, how do I get Vega to insert it into
CD-Walk? (it took about 2 years to embed the driver for KAY)
What I mean is that libraries are needed. Dynamically loaded
at the stage of program execution. Something like *.dll on a PC, only simpler.
For example, now in many Spectrum programs (for 2000-2003)
the so-called memory driver, real-time clock ("CMOS") is used,
RAM disk driver... Almost the same on every computer
a "driver" with various modifications is built into each program, or
loaded when the program starts. In the latter case, almost all
programs use drivers that are incompatible with each other, despite the fact thatthey all have approximately the same functionality. So why not
finally reach dynamic code loading and a unified method (format)
representations of this code?
In my opinion, the requirements for the library are, first of all, their simplicity
downloads. So that you don’t need an entire OS to load three hundred bytes of code.
This is extremely important for supporting libraries in the TR-DOS environment and for adapting
old programs. The second point is compatibility: there should be enough
traditional Spectrum products, such as ALASM or ZASM, both for
creating and loading the library. However, there is still something to be done here
think...
For the IDE controller driver in the CD-Hack program I used
some kind of dynamically loaded library *dll on the PC, which
allowed me to: 1. completely separate programs using the *dll file
and the library itself - now both the library and the program can develop
separately from each other (that is, releasing a new driver version does not have to
think about updating the program, and vice versa). 2. get the opportunity
dynamic (roughly speaking, I can change them on the go) loading of any of
available modules of a certain class (in this case, IDE drivers).
3. be able to download several different copies at the same time
modules of the same class (I can load all the drivers at once and use themsimultaneously on a machine with several IDE controllers). 4. Same
The module can be freely used in different programs, which greatly simplifies
its maintenance and saves disk space. List of advantages over
statically embedded code can go on for a long time... There are also disadvantages.
This is still a slight complication of the program, an increase in its volume (for example,
due to the module loader) and ineffective from the point of view of optimal
coding interface libraries and programs. For IDE drivers I had to
come up with a simple executable library file format that would allow:
1. indicate a list of imported modules and functions, a list of exported ones
functions. 2. loading by absolute and relative (movable module)
address. 3. Specify information about the module, such as its class, name and version
(I assumed that there would be a single hierarchical system
classes, so that any program can determine the purpose of the module).
I think my version of *.dll files is not the last, and while there is a possibility
for significant changes.
For os-writers and other "coders" I would suggest in more detail
discuss this topic and approve a unified format for dynamically loaded
modules. I wanted to decide on a list of requirements for the module and options
implementation. My option can be seen using the example of IDE drivers,the file with which (ide-pack.zip) was uploaded to echo today.
How's yours, Kirill?
22 Aug 03 07:54, Kirill Frolov -> All:
KF> loadable modules. I wanted to decide on a list of requirements for
KF> module, and implementation options. My version can be seen in the example
KF> IDE drivers, the file with which (ide-pack.zip) was included in the echo today.
Well, what if all the modules are non-relocatable or, moreover, compiled under
non-standard address?
WBR, Lynx // J!ZzZ!
[team ZX] [Dark Jungle] [GoA] [J!ZzZ project] [PLUt0N!um]
[GmD] [club LuK] [black-sand.da.ru]
Press RESET immediately, LynX!
On Thu, 28 Aug 03 02:58:00 +0400, LynX wrote:
KF>> loadable modules. I wanted to decide on a list of requirements for
KF>> module, and implementation options. My version can be seen in the example
KF>> IDE drivers, the file with which (ide-pack.zip) was added to the echo today.
L> Well, what if all modules are non-relocatable or, moreover, compiled under
L> non-standard address?
My modules are relocatable. For relocatable modules, the compilation address
doesn't matter. For non-movable (absolute loading flag)
address in the header must be set) the loader still returns
error. I believe that without a memory management mechanism this is not possible --
you need to know whether the requested memory is free and whether access to it is possible
loading.
But I didn’t understand your question.
How's yours, Kirill?
01 Sep 03 06:11, Kirill Frolov -> LynX:
L>> Well, what if all modules are non-relocatable or, moreover, compiled under
L>> non-standard address?
KF> My modules are relocatable. For relocatable modules, the compilation address
KF> does not matter. For non-movable (absolute loading flag
KF> the address in the header must be set) the loader returns for now
KF> error. I believe that without a memory management mechanism this is not possible --
KF> you need to know whether the requested memory is free and whether it can be accessed
KF> loading.
KF> I didn’t understand your question.
The address, if not #c000, which suits everyone, is, say, #9c40 ;).
WBR, Lynx // J!ZzZ!
[team ZX] [Dark Jungle] [GoA] [J!ZzZ project] [PLUt0N!um]
[GmD] [club LuK] [black-sand.da.ru]
Hello LynX.
Sun 7 Sep 02 LynX -> Kirill Frolov:
L>>> Well, what if all modules are non-relocatable or, moreover,
L>>> compiled for a non-standard address?
KF>> My modules are relocatable. For relocatable modules
blind and deaf ;)
L> The address, if not #c000, which suits everyone, but, let’s say,
L> #9c40 ;).
attach a sign for reconfiguring all absolute addresses,
relative to the compilation address, which may be the first
in the same sign, imh.
Thank you for your attention.
Press RESET immediately, LynX!
On Sun, 07 Sep 03 22:47:00 +0400, LynX wrote:
KF>> My modules are relocatable. For relocatable modules, the compilation address
KF>> doesn't matter. For non-movable (absolute loading flag
KF>> the address in the header must be set) the loader returns for now
KF>> error. I believe that without a memory management mechanism this is not possible --
KF>> you need to know whether the requested memory is free and whether it can be accessed
KF>> loading.
KF>> I didn’t understand your question.
L> The address, if not #c000, which suits everyone, is, say, #9c40 ;).
The address can be any, as long as it does not cross the 0xffff boundary.
There are no modules with an absolute load address yet; all modules
relocatable. That is, the address is at least #3d13, maybe, but it’s #c000
it loads, configures and works normally. So I ask again
I didn't understand.