NDK 3.1 Include file problem.

[Thorham]

Hi,

After obtaining the NDK 3.1 include files, I've been unable to use any _LVOxxx names in my source code, such as _LVOOpenLibrary and _LVOOpenScreenTagList. In the case of the exec functions in exec_lib.i, the problem seems to be that all functions need this FUNCDEF thing, and for other libraries there's no libname_lib.i at all!

What is going on here? I want to use the NDK 3.1 include files because I only have the Devpak Os 2.x includes, and want to use proper OS 3.0+ include files.

Any help is appreciated

[ChaosLord]

Either you have something assigned off to the wrong place somewhere such that you are not really using the files you thing you are using?
or
You have installed some sort of corrupted include files?
or
Your files are not corrupt and your assigns are ok but you somehow installed them wrong. Maybe you reversed the directories?  Or put them down 1 level or up 1 level from where they should be?

[Thorham]

To ChaosLord:

Nope, none of the above I'm afraid Those darned NDK 3.1 includes just don't seem to work in the same way as the Devpak 2.x includes I have (seems the LVOs are in amiga.lib).

Perhaps it's best to simply stick to those Devpak includes after all.

[ChaosLord]

I have been using Devpak 3.x for a zillion years without any insurmountable problems... Then again I don't call many os routines from asm.  For me, the whole point of asm is to avoid using the OS as much as possible

[Joloo]

Well, as far as only the LVOs are concerned, you can manually create them using the fd2pragma program:

fd2pragma TO SPECIAL 23

Unfortunately, the CALLXXX (CALLGRAF,CALLDOS) macros will not be created by fd2pragma, nor the basename macro (GRAFNAME,DOSNAME).

If I am not mistaken, I never override my NDK 3.0 include files with that of NDK 3.1 because there were a bunch of errors in those ASM-include files and I never was in the mood to fix them.

If you like, I can upload my ASM include files covering the 3.0 API.

After obtaining the NDK 3.1 include files, I've been unable to use any _LVOxxx names in my source code, such as _LVOOpenLibrary and _LVOOpenScreenTagList.

Quiet normal I would say. All versions of the SDK/NDK came without the assembler LVOs and only EXEC and REXX came with the FUNCDEF and LIBDEF defined LVOs, in addition, they can't work out of the box because the important FUNCDEF macro is put out of order (exec/libraries.i). Next, I wouldn't rely on these macro defined LVOs at all because (at least for NDK3.9) by mistake some v36 include files went into the NDK which should have been v40...
It was and is still better to create these LVOs on your own.

[Thorham]

I have been using Devpak 3.x for a zillion years without any insurmountable problems... Then again I don't call many os routines from asm.  For me, the whole point of asm is to avoid using the OS as much as possible

The problem is with functions such as LoadRGB32, which don't exist on OS2.x.

I used to hit the hardware all the time, but I want to write software that works properly under the OS now using intuition screens (but without the OS routines to write to the screen, direct access to the screen is much better). Especially now that I'm using an RGB->VGA converter.

Well, as far as only the LVOs are concerned, you can manually create them using the fd2pragma program:

fd2pragma TO SPECIAL 23

Yup, that seems to be the only good solution. I found some LVO includes on my HD and I might generate them from the C includes properly. Thanks for the tip

Unfortunately, the CALLXXX (CALLGRAF,CALLDOS) macros will not be created by fd2pragma, nor the basename macro (GRAFNAME,DOSNAME).

Not a problem, because I'm making a system frame for handling all this system stuff.

If I am not mistaken, I never override my NDK 3.0 include files with that of NDK 3.1 because there were a bunch of errors in those ASM-include files and I never was in the mood to fix them.

Hmm, I'll watch out for those then. Perhaps I'll just use the NDK 3.9 then. Shouldn't matter much, right?

If you like, I can upload my ASM include files covering the 3.0 API.

Thanks, but I don't think I'll need them

Quiet normal I would say. All versions of the SDK/NDK came without the assembler LVOs and only EXEC and REXX came with the FUNCDEF and LIBDEF defined LVOs, in addition, they can't work out of the box because the important FUNCDEF macro is put out of order (exec/libraries.i). Next, I wouldn't rely on these macro defined LVOs at all because (at least for NDK3.9) by mistake some v36 include files went into the NDK which should have been v40...
It was and is still better to create these LVOs on your own.

Hmm, quite sucky. Why did they do that? There seems to be no point...

[buzz]

captain piru to the rescue:

http://aminet.net/package/dev/asm/incupd

[Piru]

captain piru to the rescue:

http://aminet.net/package/dev/asm/incupd

Holy cr*p. That's so old I had completely forgotten about it. The oldest changes in these files originate to early 90s I believe