In article <MDBBJLBFBICIIEIHFBMEEEPLCOAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
I suspect the display weirdness comes from not having implemented some of the stubs or [not] having taken into account another global variable that affects the behavior.
BTW, the bug here was that set_attr wasn't honoring g_textrbase and g_textcbase. Now the links highlight in the right place again :-). Also, the driver abstraction slowed the help screens down tremendously. It turns out that its making a function call per-character (which in the driver translates into a whole buncha stuff going on per-character). I did a quick hack to make things better, but the help page drawer needs to be revisited to draw strings not characters.
I have found at least one global variable defined and initialized in assembler code and used in the c code, so please watch out for that.
Yep. Most of that was handled by the xfractint code since it doesn't use any assembly.
Unfortunately your very useful cross reference won't show you this particular trick.
Yeah, the vendor of that tool says they support assembler, but they don't understand the old 16-bit DOS assembler syntax that fractint uses. I use "find in files" a lot in VS.NET to find references to weird items.
Fractint is pretty scary code. That may come from the Stone Soup method of development. But I am constantly amazed that such complex code has been made so reliable. It is a testament to the dedication of the people who developed it.
Its not so much complex as it is simply huge. I may gripe about the use of global variables but its not entirely spaghetti :-). The branch is 32-bit flat address space code all the way. Far, near, huge, FCODE, etc., are all gone on the branch. I think some (most?) of the contortions the code goes through are due to the restrictions of the medium memory model. Can't put this code here, or the overlay is too big, can't put this text string here it has to go into the data segment, etc. All those issues go away on the branch and you just write code in the most natural way possible without worrying about overflowing any weird magic number size limits. No need for 'extraseg' to be aliased to 60 different data types because you can't malloc a big working buffer (or declare it staticly!). I imagine that this will be a relief to Tim and Jonathan. :-) -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>