Activity for somFree
-
somtoolkit posted a comment on discussion General Discussion
I can believe that. It is not intended to be called multiple times within an application. In reality there should not really be a need to call it when a process ends because everything allocated by the som kernel should be local to the process.
-
Yuri Prokushev modified a comment on discussion General Discussion
Hello. Just played with and found what calling somEnvironmentEnd twice raises exception in somFree, but OK in IBM SOM (both 2.1 and 3.0). clsmgr:=somEnvironmentNew; somEnvironmentEnd; somEnvironmentEnd; Also, if try reinit environmet then also exception raises. clsmgr:=somEnvironmentNew; somEnvironmentEnd; clsmgr:=somEnvironmentNew; somEnvironmentEnd;
-
Hello. Just played with and found what calling somEnvironmentEnd twice raises exception in somFree, but OK in IBM SOM (both 2.1 and 3.0).
-
Thank you
-
Yes, in order to maintain binary compatibility with IBM's SOM the va exported functions need to be using the IBM optlink calling convention. This does not exist in the MSVC compiler so assembly stubs are used to maintain the compatibility If you look in https://sourceforge.net/p/somfree/code/HEAD/tree/trunk/som/src/somobjva.c you can see the extra assembly stubs used in Win32 with MSVC A version with the true MSVC linkages are included in the somtk.lib, see https://sourceforge.net/p/somfree/code...
-
Hello. Is it correct: somva_ is a SOMLINK, va_ is a OPTLINK. And it is only difference? And it is only true for Win32, other platform both are cdecl?
-
During the IDL compilation the source file and line number are passed from the preprocessor to somipc. The idl file and line numbers are captured in the IR using the file and line modifiers. For win32 64 bit struct returns the IH uses the C compiler to determine the type size, eg look for the SOMRdRetsmallaggregate usages.
-
During the IDL compilation the source file and line number are passed from the preprocessor to somipc. The idl file and line numbers are captured in the IR using the file and line modifiers. For win32 64 bit struct returns the IH uses the compiler to determine the type size, eg look for the SOMRdRetsmallaggregate usages.
-
During the IDL compilation the source file and line number are passed from the preprocessor and to somipc. The idl file and line numbers are captured in the IR using the file and line modifiers. For win32 64 bit struct returns the IH uses the compiler to determine the type size, eg look for the SOMRdRetsmallaggregate usages.
-
BTW, I have another problem. Variadic function support. For example, Delphi support them starting from Delphi 6, IIRC. Virtual Pascal doesn't support them at all. For now I'll limit somPrintf and related things by Delphi 6 and FPC. Or need to create some wrappers BTW, because I have a plan to finish Emitter Framework it will be possible to add some new features to it. But this is not fast process, I think... Not sure I'll have free time after NY.
-
Well, it is not possible to know about includes because somcpp process file before call somipc. But source line number in the place. I don't think it is required to know something about source files. Class information is only required thing. Calling convention is a compiler specific thing. Watcom also has some problems, for example. I'll look at this problems later. By the way, is it correct that you hold some position in Novosibirsk university? It WAS correct. I'm changing work now.
-
OCTAGRAM posted a comment on discussion General Discussion
Let's not talk about solution "for Pascal". Solution for sane language it should be called, and Pascal is only guilty of being sane. By the way, circular reference is not the only reason. Forward declaration can be left unsatisfied just because. IIRC EF is missing information even for #include idl For Delphi one may need Int64 Result hack to pass around 8-byte records which are in eax:edx according to SOM vision of stdcall, but Delphi's vision of stdcall is to always pass record Result by reference....
-
You about circular reference here... Well, no good solution for pascal here...
-
I was starting with C-style bindings. They are in my repository history somewhere or maybe remaining in head. Problems were from forward declarations. Pascal/Ada permit forward declarations, but all loops have to be closed within one source. That makes Pascal/Ada very nice languages with modular structure, but hard to map WinRT, SOM and many stuff from outside world because those alien software engineers do not follow these rules. An IDL file can have forward declaration of some interface and never...
-
Hi, Ivan. May be for Emitter IR help will be required. I just restore my old archives and trying to make things work. First is a attempt to make three base classes mappers suitable for client usage. I want to produce classical mapping like in C (mostly done), and produce class wrappers (mostly works). Next question is a multiple inheritance. Here I'll need to add Delphi interfaces support, I think. After producing set of manual wrappers I have a plan to look at Emitter Framework and check is it enough...
-
Hi, Yuri. I can see you're digging hard lately. As I recall, there was a problem with Emitter Framework not enough for emitting single source file, and Interface Repository Framework was enough, but precious information was lost. And my probable solution was to make something like IR emitter, but richer, and then it should be possible to produce relatively good bindings from rich IR. Attempt to bind to Pascal was pathetic without rich IR.
-
https://github.com/prokushev/somfreepascal
-
Tested with latest omniORB 4.3.2. Also works fine. Now need to configure InterfaceRepositoy service for future tests...
-
I tried to get InterfaceDef from echo object via get_interface method. As expected, exception occur. I added get_interface to echo object with return of CORBA::InterfaceDef (based on slightly modified your version of corba.idl) and seems some result (0) was returned. Unfortunately, ORBit2 Object always returns OBJECT_NIL for this method, so I can't check is somFree correctly handles it. At least this works at first look. I need to find another ORB which support get_interface method to check above......
-
I tried to get InterfaceDef from echo object via get_interface method. As expected, exception occur. I added get_interface to echo object with return of CORBA::InterfaceDef (based on slightly modified your version of corba.idl) and seems some result (0) was returned. Unfortunately, ORBit2 Object always returns OBJECT_NIL for this method, so I can't check is somFree correctly handles it. At least this works at first look.
-
I tried to get InterfaceDef from echo object via get_interface method. As expected, exception occur. I added get_interface to echo object with return of CORBA::InterfaceDef (based on slightly modified your version of corba.idl) and seems some result (0) was returned. Unfortunately, ORBit2 Object always returns OBJECT_NIL for this method, so I can check is somFree correctly handles it. At least this works at first look.
-
That is excellent, well done! The use of somDumpSelf was very well done
-
That is excellent, well done!
-
Initial text is here: http://osfree.org/doku/doku.php?id=en:docs:tk:som:interg Any suggestions are welcome.
-
That is excellent news! You are welcome to write one and add it to the discussions here.
-
Thanks a lot. All works like charm. How about instruction about connection somFree to ORBit2? I can write one, but will need to check grammar. I'm not native speaker.
-
I'm trying to create a simple DSOM client to call ORBit2 server. IDL is simple: #ifdef __SOMIDL__ #include <somobj.idl> #endif interface Echo #ifdef __SOMIDL__ : SOMObject #endif { void echoString(in string input); }; During SOM client compilation linker expects _EchoClassData external. In SOM I just link class DLL and that's all. But I have no DLL for remote object. What I need to do to build clients? Client code: #include "echo.h" static boolean raised_exception(Environment *ev) { return ((ev)->_major...
-
Thank a lot. Will try...
-
Yes the class can exist in the exe as long as it is initialised so the class manager can find it. The echo.idl needs to be in the SOM interface repository so that when the echo methods are overridden in the client proxy class DSOM knows how to marshal the parameters and result. Yes, it should be able to read an IOR using ORB_string_to_object. You can examine the result to see what DSOM creates as a local client.
-
The interface will also need to be in the interface repository for DSOM to marshal the parameters and results of each method. Or you talk about client side? I need to add interface to client side IR?
-
I really don't want to use DII here. So, my idea was correct about echo.dll with stub methods. Is it Ok if echo stub class will be in exe where client lives, not in dll? Will DSOM handle such class? According Interface repository... ORBit2 doesn't add anything to interface repository... Another question about IOR. Is IOR standardized or ORB specific? Is it Ok to use ORBit2 generated IOR in DSOM?
-
You need to either use DII (eg SOMDObject::create_request) or provide a local client proxy class. So you need to use the som compiler to generate the local class along with stub method implementations and link that. When DSOM creates a local client proxy it tries to use the named class and create a multiply-derived class using SOMDClientProxy along with Echo. DSOM then implements each method to call create_request. The interface will also need to be in the interface repository for DSOM to marshal...
-
You need to either use DII (eg SOMDObject::create_request) or provide a local client proxy class. So you need to use the som compiler to generate the local class along with stub method implementations and link that. When DSOM creates a local client proxy it tries to use the named class and create a multiply-derived class using SOMDClientProxy along with Echo. DSOM then implements each method to call create_request. The interface will also need to be in the interface repository for DSOM to marshal...
-
You need to either use DII (eg SOMDObject::create_request) or provide a local client proxy class. So you need to use the som compiler to generate the local class along with stub method implementations and link that. When DSOM creates a local client proxy it tries to use the named class and create a multiply-derived class using SOMDClientProxy along with Echo. DSOM then implements each method to call create_request. The interface will also need to be in the interface repository for DSOM to marshal...
-
I'm trying to create a simple DSOM client to call ORBit2 server. IDL is simple: #ifdef __SOMIDL__ #include <somobj.idl> #endif interface Echo #ifdef __SOMIDL__ : SOMObject #endif { void echoString(in string input); }; During SOM client compilation linker expects _EchoClassData external. In SOM I just link class DLL and that's all. But I have no DLL for remote object. What I need to do to build clients? Client code: #include "echo.h" static boolean raised_exception(Environment *ev) { return ((ev)->_major...
-
I originally wanted to support both 2.0 and 1.1, hence somcorba but it is not practical to do so, I abandoned that effort. My goal was to make it IIOP compatible so it could talk to 2.0, this is effectively where SOM 3.0 also left it. The major issues are The _interface method is supposed to return a CORBA::InterfaceDef, not an InterfaceDef. The TypeCode APIs and data don't support both an ID and a name as required by 2.0 The IR results for describe are completely different, although they are contained...
-
I have some small improvements to SOM kernel mostly in error handling and debug/trace. They now closer to original SOM. Is it interesting? I can create diff for them.
-
Because migrated methods not public, I think it's ok to leave them as is in mapping. But CORBA_ prefix and CORBA memory manager is a question.
-
No, I don't want to change base classes. I just try do understand possible problems if I change something in them.
-
I have looked at possibility to implement CORBA 2+ compatible C language mapping. It seems to be possible mostly. But I have some problems and things need to be understood. For idl callstyle objects methods macros can be implemented easy, just put Environment at end of arguments. But for oidl calls it's a problem. SOMObject migrated methods from SOMDObject. They contains Environment argument which must be last, but not first in CORBA 2. And I don't see clean way to generate correct macro for them...
-
I have looked at possibility to implement CORBA 2+ compatible C language mapping. It seems to be possible mostly. But I have some problems and things need to be understood. For idl callstyle objects methods macros can be implemented easy, just put Environment at end of arguments. But for oidl calls it's a problem. SOMObject migrated methods from SOMDObject. They contains Environment argument which must be last, but not first in CORBA 2. And I don't see clean way to generate correct macro for them...
-
If you do make the change make sure you do rigourous testing. Static class objects and SOMClassMgr are generated in the data segment in som.dll, also make sure somDataResolve still works correctly. There may be many places which assume that SOMObject only occupies a single pointer for mtab. Also many methods that return class objects and the class manager do not increment the reference count.
-
If you do make the change make sure you do rigourous testing. Static class objects and SOMClassMgr are generated in the data segment in som.dll, also make sure somDataResolve still works correctly. There may be many places which assume that SOMObject only occupies a single pointer for mtab.
-
So, no any problem with addition of reference counter variable or any other data. It is only design limitation to prevent compatibility problems with original SOMObject (Apple's documentation mention around 2 pages about it). Thanks.
-
Currently as defined it just has the mtab pointer. To add reference counting you would need to add a private attribute to SOMOjbect itself. IBM's SOM did not have reference counting in the same way the C++ did not. If using direct to SOM you could allocate a SOM object on the stack, not the heap. The biggest frameworks based on SOM, WPS and OpenDoc implemented their own reference counting. The original WPS did not use DSOM. When Apple ported SOM to MacOS they did add reference counting to SOMObject,...
-
Ok, according protection for casted SOMObject it's less or more clean. But you mentioned about SOMObject "has no space to hold the reference count". Did you mean it is not possible to add refcounter variable or something else?
-
Look in somipc/src/rhbschdr.cpp for void RHBheader_emitter::get_function_prefix. I don't know what the difference between externalprefix and functionprefix is.
-
Functionprefix is implemented. I never came across externalprefix, or filestem. I think somfree is what it is now, if you want to extend your clones of the code you are welcome.
-
Tested on my codebase. All files emitted fine. Thank you. Is it hard to implement externalprefix alias? Btw, seems filestem and externalstem modifiers ignored also. May be some others modifiers missed, but I not checked this part yet.
-
Directory name for RHBtools
-
Permit backslash escape in passthru
-
Can you see if this fixes it, and doesn't break anything else? Index: somipc/src/rhbschdr.cpp =================================================================== --- somipc/src/rhbschdr.cpp (revision 95) +++ somipc/src/rhbschdr.cpp (working copy) @@ -8104,6 +8104,11 @@ } } + if ((i > 1) && (p[i-2]=='\\') && (p[i-1]==' ')) + { + i--; + } + out->write(p,i); out_printf(out,"\n"); } Index: somipc/src/rhbscpp.cpp =================================================================== --- somipc/src/rhbscpp.cpp...
-
Thanks for that clarification. I will have a look at the behaviour and see what I can do, no promises on when!
-
Sure, I am manually edited files for compilation. But it seems incorrect backslash processing. here citation from somobjects programming guide: "Each literal is a string literal (enclosed in double quotes) to be placed verbatim into the specified header file. [Double quotes within the passthru literal should be pre- ceded by a backslash. No other characters escaped with a backslash will be inter- preted, and formatting characters (newlines, tab characters and so forth) are passed through without...
-
Looking at wpobject.idl " #define USERWORD_FROM_PREC( hwnd, prec ) \ " " ( (ULONG)( *ShlGetUserWordPtr(hwnd,prec) ) )" The backslash escape is not at the end of the line, so no reason to treat it as a line-continuation. It effectively says treat the following space as a space. I recommend converting to a single line in the idl file to remove the ambiguity.
-
Here, for example https://github.com/osfree-project/osfree/blob/master/OS2/WPS/contrib/idl/wps/
-
manually modified files compiled well.
-
Here, for example https://github.com/osfree-project/osfree/blob/master/OS2/WPS/contrib/idl/wps/wpobject.idl
-
Unfortunately, I don't have any of the wp*.idl so I can't see what the source looks like. Are they available anywhere?
-
Hi, the idl compiler uses functionprefix extensively to provide the prefixs to internal method implementations. eg ./somir/repostry.idl: functionprefix = "m_repostry_"; ./somir/repostry.idl: functionprefix = "repostry_"; Regarding the passthru. Can I suggest you move it to the same line? The pre-processor is provided by existing platform rather than being implemented with the compiler so I can't promise how line continuations are handled. somoa.idl is an example of a passthru which emits #define...
-
I have played (again) with WPS idl files. wpobject.idl contains this in idl: #define USERWORD_FROM_PREC( hwnd, prec ) \ ( (ULONG)( *ShlGetUserWordPtr(hwnd,prec) ) ) but emitted .h file miss backslash #define USERWORD_FROM_PREC( hwnd, prec ) ( (ULONG)( *ShlGetUserWordPtr(hwnd,prec) ) ) Another problem: it seems somFree compiler doesn't support externalprefix = obj_; line. As result, all functions comes without obj_ prefix. As result compilers warns about missed functions C:\yuri\osfree\build\OS2\WPS\PMWP\wpobject.ih(38):...
-
somFree released /MacOS/11.0/SOMTK-11.0-1.0.0.95.pkg
-
Changed CFBundleIdentifier to net.sf.somfree.somtk
-
test somtestl only wint x86
-
Cool, let me know if there are any problems. I have added some tests, ... somtesta - tests alignments of data structures somtestl - tests the class data structures against som30nt to validate releaseorder etc somtestv - tests class construction and substitution the existing somtest0 is there mainly to test the somtc va_arg methods which is the trickiest part when porting to different CPU ABI.
-
Thank you!
-
-
Use host SC in tests
-
Correcting detection of migrated methods
-
https://sourceforge.net/p/somfree/code/91/ This adds the requested macros.
-
-
-
Expanded test cases and source code compatibility macros
-
-
I have created an MSI for the original som30nt. The PowerShell script to make it is here... https://sourceforge.net/p/somfree/code/HEAD/tree/branches/som30nt/package.ps1 I have uploaded a packaged one here. https://sourceforge.net/projects/somfree/files/IBM/ It installs as a 32bit application in %ProgramFiles%\IBM\som30nt. When building the MSI, I include the output from both somstars.bat and somxh.bat.
-
-
MSI for IBM som30nt
-
Imagine you are writing a DSOM application. When doing DSOM two things happen... All remote objects are derived from both the actual interface and SOMDClientProxy You have to do SOMDObject_duplicate and SOMDObject_release to manage memory So you get used to dealing with objects that have the real business interface, and casting it to SOMDObject to do the reference counting. Now what happens when you are given a non-remote object, that is not also derived from SOMDClientProxy, it is just the plain...
-
SOMObject can't do reference counting because it has no space to hold the reference count and it would be a fundamental change in behaviour. What it means is you can have another class derived from SOMObject, for example SOMRefObject and that can implement the reference counting. Then you can use SOMDObject_duplicate and SOMDObject_release and SOMRefObject will do the right thing, even though it is not actually a SOMDObject. Have a look at somref.c and somref.idl to see what I mean.
-
So, not clear why migrate methods and have empty implementation? Not finished work or another problems with implementation?
-
Microsoft were never supposed to work on this. Windows as we know it, is produced by division of labour. Intel defines binary object formats: first OMF, then PE. Microsoft writes kernel. Borland provides development tools, and now it's Embarcadero who is in charge for Windows development. Sometimes Microsoft managed to accelerate progress by kicking Borland. Microsoft made UTF-16 the only encoding in COM, and reference counting as the main memory management policy. Without that kick Borland was not...
-
Regarding user interfaces it is disappointing to see Microsoft not know what it is doing and leaving developers truly wondering what they are supposed to do. UWP and Windows Store was the big thing a couple of years ago, now they are abandoning it, WinUI3 is supposed to be the new thing, or is it now MAUI? If I was going to do a cross platform UI now, I think today I would use Qt5. At least it is still truly a cross platform solution, even Blackberry's Cascades UI used Qt underneath.
-
Regarding user interfaces it is disappointing to see Microsoft not know what it is doing and leaving developers truly wondering what they are supposed to do. UWP and Windows Store wa the big thing a couple of years ago, now they are abandoning it, WinUI3 is supposed to be the new thing, or is now MAUI? If I was going to do a cross platform UI now, I think today I would use Qt5. At least it is still truly a cross platform solution, even Blackberry's Cascades UI used Qt underneath.
-
AFAIK DCE had no reference counting. So Microsoft could possibly also maintain compatibility with something, this time DCE, and build trash that nobody likes after all, and nobody cares about DCE compatibility after all. I think, another more serious reason for ugly SOM without RC was C++ D2SOM. I was wondering why IBM didn't provide rich frameworks based on SOM. I install VisualAge for C++ 3.5.9 on Windows. D2SOM is not abandoned yet in this version (it will happen in 3.6). SOM is the way to go....
-
Where as COM, which was contemporary, all it could do was reference counting and ask for other interfaces. Eg everything starts with IUnknown with QueryInterface, AddRef and Release.
-
But, SOMObject has no implementation for reference counting, it does not increase its size to hold a count. All it will do on duplicate_reference and release is not crash!
-
Hi, yes, the easter egg was found after twenty years! So my take on the history of SOM goes like this... SOM 1 was just really just SOM.DLL and the compiler, it had its own IDL format, now known as oidl. WPS was built on this. SOM 2 was built to be CORBA 1.1 compliant, hence SOMTC, SOMIR and SOMD. Also along for the ride was a new IDL language based in CORBA with SOM extensions. Hence the SOMIDL macro. SOM 3 was built to be CORBA 2.0 compliant, and hence support IIOP and other such fun. Now between...
-
Hello. While researching somFree internals found some methods moved from SOMDObject interface to SOMObject interface. Is any reason fot this? In IBM SOM 3.0 in releaseorder such methods named as private, so I consider same thing was also in IBM SOM 3.0.
-
In my original plan, I was going to have SOMDD manage the interface repository and then each other process would access it using ORB_resolve_initial_references(SOMD_ORBObject,ev,"InterfaceRepository"); This was for machines that may only have had 8MB of RAM, so saving it was important. Each process would have treated it as read-only using existing defined interfaces but SOMDD would have held it in a database and allowed it to be updated.
-
Simplicity is: Forgetting SOMEF ever existed Extending SOM.IR to contain explicit types, comments and passthru Wielding SOM compiler with extended IR emitter and pretending it was always united like this Rewriting other emitters to work with extended IR
-
I forgot one more thing. Why does it fail with SOMEF as is. Emitter receives just a single class definition. Even if you force SC to see all the forward definitions, emitter won't receive them. Won't be able to perform topological sort and other nontrivial actions like copy-pasting parent class methods into current bindings.
-
May be be simple? Just add option to Algol-like emitters which will require add more idls to resolve all forwards? Such emitter will maintain database (like somir, but not public) to construct full dependencies list? Then calling will be like this sc -sdelphi -mi=som.idl scemit.idl
-
Indeed, they fail. But what do you propose instead? Imagine you have an empty SOM.IR database. It's the very first invocation of ir emitter, and some forward definition remains unsatisfied. I can gather a self-sufficient database and produce a good looking bindings. I mostly agree, but there are still some options to choose from. I can reject incomplete databases. I can map to SOMObject. I can map to SOMObject descendant without any additional methods, but that will make it incompatible with random...
-
If you do so, then dynamic languages will fail to find real classes. IR used to list SOM classes available. You can't do nothing with this due nature of IDL Again, you can do nothing with this. Only solution is full dependences in via IDL includes. Otherwise it will be SOMObject.
-
Then how ir emitter is supposed to work? It does exactly this. Adds references to unknown classes. Then, hopefully, during some next ir emitter invocation reference will be resolved. This is not strong typed approach. I don't like it. Duty of the developer. In vanilla SOM.IR there were 2 or 3 class references remaining unresolved. I can consider it to be a bug, but to make things work I have mapped them to SOMObject. SOM revolves around DLL which cannot have circular loops. So those DLL shall have...
-
You are correct about enterprise middleware. But for OpenDoc and WPS (as local object system) SOM still good solution.
-
Ah. You about THAT problem. Yes. It is known problem. It is IDL related thing. And your solution with SOMIR is not real solution. SOMIR must contain implemented classes, not still in development. So adding not yet implemented classes to SOMIR... Hmm.. So-so solution. IDL can contain only forward interfaces without any link to idl with interface declaration. Then forwards only mapped to SOMObject. We can add something like SOMIR (or meta-IDL) but are you sure it will always contain actual interface...
-
On my two ex-jobs and on my current job we use semi-COM to bridge Delphi. Different Delphi versions or independent RTLs. This semi-COM does not require registration. Semi-COM objects are obtained via DLL function. Developers just know that they must: Use WideString for all strings Use safecall for all methods Don't use closures Only reference to semi-COM and COM interfaces Either avoid changing interfaces or implement versioning Delphi safecall acts as exception firewall. It converts Result into...
-
Indeed, I would drop that CORBA trash. And memory management was a garbage. Not hopeless, but if we make something sensible, then old code won't fit. SOM is similar to Objective-C, but as you may see, Objective-C managed to polish its shortcomings. Objective-C did not have reference counting. It has got manual reference counting. Then some compilers implemented automatic reference counting. The same could be done to SOM, to some degree (not sure what to do with sequences and unions). It all can be...
-
Because emitters operate in the massive lack of information. IDL can contain forward class declaration and define methods operating with this class and structs having fields of this class. But forward declaration can remain never satisfied. In a strong typed language I naturally want to map typed class reference to the appropriate language projection. Strong typed languages have a restricted syntax for looped types. For instance, in Delphi there are 3 forward type definitions: type TSomething1 =...
1 >
