Activity for somtoolkit
-
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.
-
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...
-
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.
-
That is excellent, well done! The use of somDumpSelf was very well done
-
That is excellent, well done!
-
That is excellent news! You are welcome to write one and add it to the discussions here.
-
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.
-
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 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...
-
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.
-
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,...
-
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.
-
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!
-
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.
-
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...
-
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.
-
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.
-
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.
-
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...
-
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.
-
SOM was good for its day and was a good basis for both OpenDoc and WorkPlaceShell. However OpenDoc was killed off by Steve Jobs and WorkPlaceShell stayed OS/2 only despite plans for AIX etc. I am not sure who still uses CORBA any more except IIOP did replace Java RMI in J2EE implementations. But “idlj” and other CORBA was removed in Java 11. For code development today we need to be using memory managed languages, SOM is not part of that world. Just like people don’t really do COM and OLE anymore...
-
Hi, Yes, not all the macros were done. But more importantly SOM_TraceLevel does exist and SOMClassMgr does implement a working somSubstituteClass. The code in Christina Lau's book compiled, so that was an achieved goal. I did not really get involved with the SOM emitter framework, my approach was quite different, my C++ program basically built an InterfaceRepository holding all the data from the source IDL. My rational was different, I was porting it to other platforms and had a chicken-and-egg problem...
-
Well spotted! The last digit is the SVN revision number. https://sourceforge.net/projects/somfree/files/Win32/ The reason is historical, the earlier MSI were built using MakeMSI and from a different SVN repository. The POSIX builds were always built from somfree. Now the Windows builds are also done from the same repository but using WIX and rhbtools. So the minor version number was incremented to show they come later.
-
Well spotted! The last digit is the SVN revision number. https://sourceforge.net/projects/somfree/files/Win32/ The reason is historical, the earlier MSI were built using MakeMSI and from a different SVN repository. The POSIX builds were always built from somfree. Now the Windows builds are also done from the same repository but using WIX and rhbtools. So the minor version number was incremented to show they come later.
-
Code Signing Certificate for Win32 MSI -----BEGIN CERTIFICATE----- MIIDsTCCApmgAwIBAgIQC7LzmrqH57FOwfxusRIM9jANBgkqhkiG9w0BAQsFADBB MSYwJAYJKoZIhvcNAQkBFhdzb210b29sa2l0QHVzZXJzLnNmLm5ldDEXMBUGA1UE AxMOc29tZnJlZS5zZi5uZXQwIBcNMjIwNzE5MTkzOTQ0WhgPMjEyMjA3MTgyMjAw MDBaMEExJjAkBgkqhkiG9w0BCQEWF3NvbXRvb2xraXRAdXNlcnMuc2YubmV0MRcw FQYDVQQDEw5zb21mcmVlLnNmLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKbYMqGE2tLd7L9mOgHElmmKCuTfe5rY+ZTCGEQ4MYGNhPIvu02f55Ps 7w8I+TpHIN9Td5Nqa799xcotqGopilwLZsFzWCdIaG9nWjfBm5Keo0vUJIQ544nv...
-
data_seg for constant typecodes
-
https://sourceforge.net/p/somfree/code/HEAD/tree/trunk/som/src/somobjva.c This is a hairy piece of code because IBM's SOM.DLL still had some optlink functions. As the advice says, use the somva_* versions instead if you need to.
-
default data_seg for method tables is .text
-
I got to the bottom with what had happened to DEP. I was previously putting the method tables in #pragma data_seg(".text","CODE") But when I looked at the MAP file for SOM.DLL, these had been put in a segment called .text but it was marked as DATA. Hence the violations when trying to run the thunking code. https://sourceforge.net/p/somfree/code/87/ It seems that Microsoft now put their code in a segment called ".text$mn". So that is what I now do and am able to remove the /NXCOMPAT:NO flag.
-
Use data_seg .text$mn
-
Build and install somtk with make make test make dist products\win32i86\Release\dist\somtk.msi Change to samples directory and set up somtk C:\Users\rogerb\source\repos\somfree-code\samples\clau\book\chap2>"C:\Program Files (x86)\somtk\bin\somenv.cmd" C:\Users\rogerb\source\repos\somfree-code\samples\clau\book\chap2>echo %SOMBASE% C:\Program Files (x86)\somtk C:\Users\rogerb\source\repos\somfree-code\samples\clau\book\chap2>echo %SOMIR% C:\Program Files (x86)\somtk\etc\som.ir Then make with nmake....
-
Do you still have the Visual Studio compiler settings set in that session? sc.exe uses the cl.exe to provide the pre-processor, so it must be on the path. What "make" are you using? With Visual Studio you should be using nmake.exe
-
build
-
build
-
Thanks! I have updated the instructions.
-
build
-
Interesting. I started using VirtualAlloc to solve the problem then switched to HeapCreate(HEAP_CREATE_ENABLE_EXECUTE,0,0) to allocate the special memory. That worked for Visual Studio 2010 but not Visual Studio 2013 it seems, going by the commit history.
-
For clarification... I compiled with the somFree headers and libraries. The executables I modified with /NXCOMPAT:NO were the newly compiled samples. None of the IBM som30nt files were modified. So I think that is the best of all worlds.
-
For clarification... I compiled with the somFree headers and libraries. The executables I modified with /NXCOMPAT:NO were my own programs. None of the IBM som30nt files were modified. So I think that is the best of all worlds.
-
Thanks, however I am happy with the version from hobbes, I used to use them years ago. I am trusting that as an original IBM release and it works, even with the current Visual Studio 2022 compiler as long as you add the /NXCOMPAT:NO to the link parameters. You were refering to alignments, I am using the default alignment for Visual Studio. That should align to what you say IBM was using in Visual Age for som30nt.
-
environment for %ProgramFiles(Arm)%\somtk
-
MSI for Windows ARM64
-
One implementation difference with somFree and IBM's SOM is that somId are treated case-sensitive. For example in the samples chap4/dynaload, the IBM's SOM will load class "Cat" when asked for class "CAT" or "cat". But somFree does not. somId are fundamental for both methods and classnames, and case-sensitivity was simpler.
-
https://sourceforge.net/p/somfree/code/84/ I have added /NXCOMPAT:NO to the Win32i86 builds and samples.
-
link Win32i86 with /NXCOMPAT:NO
-
Back to the original question. I have tested chapters 2, 3, 4 and 8 from the Christina Lau samples, see https://sourceforge.net/p/somfree/code/HEAD/tree/trunk/samples/clau/book/ I used Visual Studio 2022 on Windows 10. I used somtk-1.0.0.4042.msi from https://sourceforge.net/projects/somfree/files/Win32/msvs2010/ Check the installed "include/somnames.h" to confirm it is enabling the method thunking. I used som30nt.zip from https://hobbes.nmsu.edu/download/pub/windows/som30nt.zip The good news is...
-
https://sourceforge.net/p/somfree/code/5/ https://sourceforge.net/p/somfree/code/29/ So it looks like it first started having problems with DEP around Visual Studio 2010, this was resolved, and then returned with Visual Studio 2013. Another issue is decorated exports in DEF files, it looked like the IBM DLLs themselves don't use decorations but the generated DEF files do. By that I mean a C export with underscore prefix and then a trailing @ with count of bytes in the arguments.
-
Oh dear, there must have been a reason I did this. https://sourceforge.net/p/somfree/code/HEAD/tree/trunk/somkpub/include/somnames.h I disabled the generation of the thunking stubs for Visual Studio 2013 and later. So everything goes via somResolve/somDataResolve in the generated code. That said, if the SOM.DLL is generating the thunks correctly you should be able to enable it in the code using it.
-
Hm, https://sourceforge.net/p/somfree/code/HEAD/tree/trunk/somkpub/include/somnames.h I disabled the generation of the thunking stubs for Visual Studio 2013 and later. So everything goes via somResolve/somDataResolve in the generated code.
-
cast for MSVS2022 WIN64
-
build
-
The original IBM somtk 2.1 and somtk 3.0 have a few problems on Win32 due to the tightening of executable restrictions. somFree resolves this with allocating memory with the executable flag set when allocating memory for the method tokens. I would tend to focus on somtk 2.1, it was deployed in every OS/2 2.0 workstation and was also included in OpenDoc for Windows and AIX. There was even "SOMobjects for MacOS" in both CFM-68k and PowerPC. The somref SOMRefObject was suggested by the Apple port. som...
-
Updated build instructions for Windows https://sourceforge.net/p/somfree/wiki/build/
-
build
-
build
-
netcoreapp3.1
-
Wrapper script for building on an OpenWrt device
-
No filter used, removed build_id_links
-
slackware
-
Changes for usr/share/somtk to usr/lib/somtk
-
move from usr/share/somtk for usr/lib/somtk for Linux
-
gnuelf lib64
-
root directory changed for gnuelf platforms
-
Add rpath to apps
-
Add rpath to apps
-
Add rpath to apps
-
Add rpath to apps
-
Add BSD packaging and runpath to apps
-
Package builders for Gentoo and Alpine
-
config.mk depends on config.h and config.hpp
-
Packaging for Solus and ArchLinux
-
Updating for OpenIndiana
-
Patche for buffer overflow compiler errors
-
Fix compiler errors on string operations
-
Empty recommends removed
-
GNU debian 0.9 GNU-Mach 1.8+git20210809-486/Hurd-0.9 i686-AT386 GNU
-
Added RISC-V endien detection
-
NetBSD update and compiler fixes
1 >
