Closed Oleg-N-Cher closed 10 months ago
Hi,
I have modified Pow32/link32/Obj2exe.cpp to handle this case, which is in itself weird. The symbol is present in the LIB file, but it points nowhere.
Just to note, you should use MS Visual C++ 5.0 compatible LIB files, because Link32 cannot handle anything else.
Regards, pahihu
Dear pahihu, thank you so much for coming forward.
I checked out your fix. Yes, your correction does fix the crashing out Pow! while linking the example. But check it with the example _oberon.zip after the applying your fix (by replacing link32.dll): the files oberon.dll, oberon.EXP and oberon.LIB are still not generated even when I revert back the name of the last procedure to DllEntryPoint. And before (without the fix) they were generated in this case. I'm afraid your fix is not enough and further research is needed...
With DllEntryPoint and your fix applied (oberon.dll, oberon.EXP and oberon.LIB were not generated):
Without your fix (oberon.dll, oberon.EXP and oberon.LIB generated):
I apologize for misinforming you. I tried to remove @1 and @2 from link32.def, which I shouldn't have done. In fact, the problem after your fix looks like this:
As you can see, the DllEntryPoint entry point is present, but the linker does not see it. Try to reproduce it for yourself and forget about both my previous posts.
P.S. Is there anything that can be done about these warnings?
d:\projects\pow\pow32\link32\debug.cpp(3333) : warning C4700: local variable 'symInd' used without having been initialized d:\projects\pow\pow32\link32\debug.cpp(3565) : warning C4700: local variable 'symInd' used without having been initialized ... d:\projects\pow\pow32\link32\section.cpp(2111) : warning C4244: '=' : conversion from 'unsigned long' to 'unsigned short', possible loss of data d:\projects\pow\pow32\link32\section.cpp(412) : warning C4700: local variable 'actInd' used without having been initialized ... link32.dll - 0 error(s), 4 warning(s)
Hi,
A hope finally fixed it. The exported symbols should be defined in the OBJ files and not imported from elsewhere in LIB files. The linker checked the exported symbols but resolved them in any OBJ or LIB file, and it assumed that is defined locally.
Regards, pahihu
Yeah, after your last fix the example definitely working well now.
Oh, I hope it doesn't cause any side effects. It's just too complicated for me. I'm glad you're here. 🥇
Unfortunately, Pow! hasn't gained as much popularity (relatively) as BlackBox or XDS (maybe because of the license in oberon2.lic: "Educational and Private use only". What do you think about it?
You are a very cool expert. I should put your name in credits.txt, as soon as you tell me your name. Thank you very much!
P.S. One my colleague, who is not on GitHub, started rewriting powsup, powedit, pow and _oberon from C to Oberon-2 with the goal of getting rid of Visual C and building Pow! itself. I think there's complex debugging involved, and the whole thing is fraught with bugs. And the small number of users would make this work almost pointless. But it's still good that someone is still doing something on Oberon.
Hi,
Yes, BlackBox and XDS are nice.
Regarding the Oberon-2 compiler icence, it would be great if someone asks Robinson Associates about the usage restrictions, if any.
There was a project rewriting POW in Oberon-2 by Klaus Schonberg back in 2003. I have the sources if you are interested.
My real name is Andras Pahi.
Regards, pahihu
On 2023. Dec 29., at 14:10, Oleg N. Cher @.***> wrote:
Yeah, after your last fix the example definitely working well now.
Oh, I hope it doesn't cause any side effects. It's just too complicated for me. I'm glad you're here. 🥇
Unfortunately, Pow! hasn't gained as much popularity (relatively) as BlackBox or XDS (maybe because of the license in oberon2.lic: "Educational and Private use only". What do you think about it?
You are a very cool expert. I should put your name in credits.txt, as soon as you tell me your name. Thank you very much!
P.S. One my colleague, who is not on GitHub, started rewriting powsup, powedit, pow and _oberon from C to Oberon-2 with the goal of getting rid of Visual C and building Pow! itself. I think there's complex debugging involved, and the whole thing is fraught with bugs. And the small number of users would make this work almost pointless. But it's still good that someone is still doing something on Oberon.
— Reply to this email directly, view it on GitHub https://github.com/Oleg-N-Cher/POW/issues/2#issuecomment-1872074261, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADTEB23FEG2BTFO46Q6C5WTYL26K7AVCNFSM6AAAAABBFWFZICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGA3TIMRWGE. You are receiving this because you commented.
You forgot to mention that Ofront+ is nice too! ;)
Judge for yourself: five input languages (Oberon, Oberon-2, Oberon-07, Component Pascal and my own Oberon-3 dialect), and all can be mixed in one project. It is also possible to insert chunks of C / asm code. Works as a command line utility in all UNIXes, *BSD, macOS and Windows on any processor. Use any C compiler (tested with GCC/MinGW, Clang, Tiny C (tсс), Turbo C, Hitech C, SDCC, cc65). I used Ofront+ for develop games for retro-computers like Commodore 64, Atari or Sinclair ZX Spectrum.
I heard Robinson Associates broke up. I guess there's no one to ask. Although the site is still alive. If you have any connections to the university or any of the authors of Pow! - let me know please.
Yes, POW rewriting in Oberon-2 is very interesting. Please send me the sources at allot {a} bk.ru Alternatively, you can just create a repository for them.
Do you use facebook or telegram?
Thank you very much for your help, Andras!
Two things must happen to reproduce this linker error:
If obrn32.LIB is absent in the list of dependencies, Pow! shows missing DllEntryPoint as error:
If obrn32.LIB is included and DllEntryPoint is absent then a critical failure occurs. Compilation happens, but Pow! just closes with an error when linking. On older Windows it looks like this:
The archive with a minimal example reproducing the bug. _oberon.zip