It is possible to build aos4 native library which will works fine, without opening of IFaces in the code of library at all _manually_ ? I already use __USE_INLINE__, but as it library i can't use -lauto, so i have bunch of undefs on linking to IFAces.
The problem, is that code which i trying to port heavy use libbases in all kind of conditions, its just define/undef them as need it in whatever place. For example for DOSBase in different sources different defines:
So i can't make some global IDOS for all the times (i do one of course, when i open all the libaries in init.c). But then , later they play with it there and there . Do define them, and then undef them. And i do not know how to follow that for os4 library .. should i add opening of IFace right after any #define to DOSBase happens ?
Besides, code put those defines not in functions, but just in meantime. Like:
function1() function2() #define to DOSBase function3() #undef DOSBase function4() function5()
So i can't let's say write a stirng which open IFACE right after define happens (as it will be code, which i can do only in functions).
In general any solution will be fine: or build working library without worring with IFACes (some magic -D flag on linking or whatever), or if somebody can help me out with ideas of how to do all that stuff with all those libbases, that also can be helpfull.
But why dont you open yourself (say) DOSBase in YourLibrary's LibInit then define it as an extern struct DosLibrary* DOSBase; in all the other source-files
So other file like (say) foo.c will no more use (say) data->dos_base but YOUR DOSBase but that is not a problem
It is possible to build aos4 native library which will works fine, without opening of IFaces in the code of library at all _manually_ ?
No you must open your libs and interfaces in the library init or open code depending on where that is most relevant. (Usualy init).
Quote:
The problem, is that code which i trying to port heavy use libbases in all kind of conditions, its just define/undef them as need it in whatever place. For example for DOSBase in different sources different defines:
That's what the code is doing allready or what you have done? Quote:
.
So i can't make some global IDOS for all the times (i do one of course, when i open all the libaries in init.c). But then , later they play with it there and there . Do define them, and then undef them. And i do not know how to follow that for os4 library .. should i add opening of IFace right after any #define to DOSBase happens ?
Okay I see, one thing then could be to open the interface immediately after the base was open. Then make a local macro.
The best most flexible way IMHO is not to use __USE_ILINES__ and use IDOS->SomeFunc() then you make full use of the flexibilty of the local interface approach, but ofcourse it make it harder to keep code cross compatable.
Another way might be to split out this hacky code into seperate files.
But why dont you open yourself (say) DOSBase in YourLibrary's LibInit then define it as an extern struct DosLibrary* DOSBase; in all the other source-files.
Its not my own code, its dopus5.library, which quite big and i want to make a first port with as less as possible changes and rewriting, just to avoid loosing any single bit which i do not know , or can just miss.
Quote:
So other file like (say) foo.c will no more use (say) data->dos_base but YOUR DOSBase but that is not a problem
Code of library uses a lot of different datas, structures, defines, redefines, defs and undefs in all possible places. One time in some file DOSBase define come from (((BufFile *)file)->dos), another time from another structure and defined as (data->dos_base) and so on. In different places code reacts and fills necessary structures different, and i can't say where and how they fill all of this all the time. All what i can now, it just somehow follow the way they do originally, and make those IFaces works as need it in their structs,etc.
@Andy Quote:
That's what the code is doing allready or what you have done?
Sure not me, i will never define and redefine bases of libraryes anywhere in code, enough to open it one time in init and follow one global base/iface. But author of dopus5 do it like this and because they want to allow patching, and because at time when they write code no one worry if there can be "IFace" for anything :)
I anyway have a good hint from Thore, which mean adding of IFACE to the dopus5 struct LibData, and then use the same "define/redefine" way as they do for library bases. So by that way i can follow their logic without rewriting anything. At least first native build should be changed as less as possible , to avoid new bugs.
can you not add an Interface reference in addition to the Library reference pointers and fill it in locally for every structure concerned (where they are private)?
you can then localize "DOSBase" and "IDOS" references keeping the "__USE_INLINES__" for the function calls and fixing the relative usages when they get too strange right?
I've got one codebase where I need at least three sets of opening libraries and obtaining Interfaces within a single project.
and the dopus5.library from your description sounds eerily familiar to what I am overcoming for the same kind of problem
@all Can obtained interfaces "die" while program works ? Why i ask, its because i have pretty strange problem. We have dopus5.libray, in init of which we open libraryes and obtain their ifaces. All is fine. Then, when we use that library from os3 binary all is fine. But when we use that library from os4 binary (by any single test case), then on exit we have crashes in library related to dos functions, which we solve by commenting out of droping of IDOS (just keep a closelibrary() ) or by adding one more "get IDOS" line in some part of code.
Question is: how it can be possible that the same library works ok from os3 binary, but crashes on dropiface when used from os4 library ? Library the same, so it should crashes from any binary imho then ? Can it be that when we build os4 binary IDOS from it somehow interact with IDOS from library and "kill" it ? Sure, sounds stupid, but dunno what to think ..
It is possible that maybe library init yourself, then run some tasks, then while binary exit (and auto close their ifaces) its somehow close ifaces of task running from library ?:))
Any tip about how to debug that also pretty welcome
of course something nasty .. bugs happens because of some done something nasty. as for debug printfs: of course i use them from beginning (how else we debug library before :) ).
Questions mostly theoretical, in end of all everything come to debug printfs..
// Miscellaneous startup code
void startup_misc_init()
{
// Set wildstar bit in dos
DOSBase->dl_Root->rn_Flags|=RNF_WILDSTAR;
// Get pointer to our Process structure, and hide requesters
main_proc=(struct Process *)FindTask(0);
main_proc->pr_WindowPtr=(APTR)-1;
// Complement some strings
compstr(register_name);
compstr(about_1);
compstr(about_2);
eliza_decrypt();
}
I.e. right before opening of any libraries or so. Its just first strings in the main().
It didn't compiles, because says that RNF_WILDSTAR undeclared (and i can't find out it in whole SDK as well).
So, we go that way:
// Miscellaneous startup code
void startup_misc_init()
{
// Set wildstar bit in dos
#ifdef __amigaos4__
DosControlTags(DC_WildStarW, TRUE);
#else
DOSBase->dl_Root->rn_Flags|=RNF_WILDSTAR;
#endif
// Get pointer to our Process structure, and hide requesters
main_proc=(struct Process *)FindTask(0);
main_proc->pr_WindowPtr=(APTR)-1;
// Complement some strings
compstr(register_name);
compstr(about_1);
compstr(about_2);
eliza_decrypt();
}
But have crash right at first compstr(register_name) line (while for os3/mos it work ok, so code by default ok).
Then i just tryed to grab defines from os3/mos sdks, and do it like this:
@Salas00 Changed, still crashes :( Maybe that "|=" OR should be done different then.. Or maybe for os4 we firstly need to open dos.library to make that call works..
What is that code doing? If it modifies the string in place, permanently why not just replace it with the modified string?
I can't say what code of dopus5 doing. I.e. i can say: its doing everything in all kind of places :) There is already milion of functions, changing of which will leads to all kind of problems and crashes. So, structure of the code should be remain the same as much as possible, with less as possible "rewriting", at least on beginning. Or bug-hunting can end-up with nightmare.
But in general code do exactly that:
main()
{
startup_misc_init();
.....
}
void startup_misc_init()
{
// Set wildstar bit in dos
#ifdef __amigaos4__
DosControlTags(DC_WildStarW, TRUE, TAG_END);
#else
DOSBase->dl_Root->rn_Flags|=RNF_WILDSTAR;
#endif
// Get pointer to our Process structure, and hide requesters
main_proc=(struct Process *)FindTask(0);
main_proc->pr_WindowPtr=(APTR)-1;
// Complement some strings
compstr(register_name);
compstr(about_1);
compstr(about_2);
eliza_decrypt();
}
And compstr() and register_name() chars are as i show in previous post.
Later that register_name value used in all the places and many functions.
ps. to add, os3 binary works ok in that terms. But thats of course because os3 sdk was used but whatever ..
DosControl -- Set or obtain global DOS PREFS values. (V50)
This function provides a single method for reading or setting various features available in the V50+ dos.library.
This is the primary interface for the DOS PREFS tools, which uses this function to implement the users prefered default settings. It is therefore recommended that applications use this function only to read what the user has chosen and not to flippantly override them.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you must change any values, read the previous setting and restore it after you have finished, you should never permanently change the users prefered settings without expressly having permission to do so.
Please just remove this stuff (below) and let the user decide what they want, with the DOS prefs tool.
You cannot port applications without having someidea what it's doing.
Quote:
So, structure of the code should be remain the same as much as possible, with less as possible "rewriting", at least on beginning. Or bug-hunting can end-up with nightmare.
Not possible in this case, you cannot modify strings in the code section on AmigaOS4, people howl for memory protection then complain the OS is broken when they get it
Based on the code clip you show me it looks like those strings are not accessed before those complimenting function are called. therefore just replcae them with the complimented versions and remove the compliment function calls. See what happens.
I suspect this is part of the copy protection / registration . Thus not needed. Why else would you obsfuscate strings in the code?
Its not my code, its dopus5. I can't for now remove anything, because i do not know how programm will reacts after. That to do for times when initial and original version will just works in native forms.
@andy Quote:
I suspect this is part of the copy protection / registration . Thus not needed. Why else would you obsfuscate strings in the code?
Yep, its about registration as far as i can see.
Quote:
You cannot port applications without having someidea what it's doing.
"some" idea is key here :)
ps. removing of registration's help, but still need to check all possible places.
kas1e wrote: Its not my code, its dopus5. I can't for now remove anything, because i do not know how programm will reacts after. That to do for times when initial and original version will just works in native forms.
Well, in that case, if you can't remove anything because it might cause problems, then I would respectfully suggest that you absolutely must -not- add something wrong that would make the situation worse.
As I said, using DosControl() in this manner is completely wrong ! Please read the autodoc again. It's the primary interface for the DOS prefs tool, not for applications to mess with flippantly.
If you want to leave the old code alone so as not to cause porting problems, then all you needed to do is this;
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
