home *** CD-ROM | disk | FTP | other *** search
- At present, there are no real bugs known to me
- (the problems that version 1.0 beta had are
- fixed in this release, see HISTORY).
-
- But maybe this place is appropriate to speak
- of general deficiencies as well:
- VCB is probably not as portable (to other
- compilers) as it should be.
- My development system is Manx/Aztec and
- although it's a thing of love and hate
- (more hate, after all) I will not migrate
- to SAS in the near future.
-
- Therefore, I'm not able to support SAS
- actively.
-
- I'm not speaking of compiler warnings
- but of fatal system failures that may
- only show up if you don't think of it!
-
- It is in the nature of a gadget class
- that parts of its code are executed in
- the input.device's environment. What that
- means to the type of code your specific
- compiler generates and what measures are
- appropriate to avoid problems, I cannot tell.
-
- The actual problem, however, lies deeper:
- An object class is meant to be re-usable
- and this only makes fully sense if the code
- is re-usable itself. That is, VCB should
- not be a linker library but should be
- memory-resident and accessible by its symbolic
- name for all clients at run time.
-
- Due to Commodore Amiga's regulations (which
- I do not want to question), I cannot simply
- go ahead and make the class public myself
- but must submit it to Commodore Amiga for
- having its public name registered.
-
- I will not do so until I'm confident that
- all dangerous bugs that VCB still may have
- are positively defeated.
-
- Presently, I'm thinking about re-writing VCB
- in assembler (for A68k and a/blink, having the
- two benefits of being easily available and being
- Amiga Object File compatible).
-