Conceptually this is not difficult at all. I was until recently responsible for a large commercial product written in C++. I did all of the alpha unit testing in Visual Studio on Windows. It was not a "useful product" on Windows (because of differences in the environment external to my code) -- you could not have sold it as a commercial product for Windows -- but 95% of the code "worked" at least at the unit level.
It all depends as I wrote below on the problem to be solved. Some business problems are very different technically on Windows. The product I describe processed SMF records. Windows does not report events using SMF records, so the business problem is very different, but all the bits and pieces of processing them work the same on Windows. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, July 2, 2019 1:20 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: C DLL Code from Assembler Plain and simple I need to write code the majority of which is same in both a windows platform and z/os hence C/C++ I can encapsulate the different function and export them In z/os it would be called from Assembler in Windows from MFC C/C++ > On Jul 2, 2019, at 4:09 PM, Jon Perryman <jperr...@pacbell.net> wrote: > > This is really vague and I think there may be some misunderstanding of terminology. > Why are you asking about Metal/C? Is there some importance to this? MetalC may be missing functions you need. MetalC is an implementation of C that can be used within z/OS (e.g. SMF routines). Several functions are missing because they are not compatible within the OS (e.g. dllload because it does an MVS load). > Why are you discussing DLL? MetalC can be part of a DLL but a MetalC program is not designed to call a DLL. Other than implementation and benefits of how a specific function is called, this information may be more co ? > You mention #IFDEF to exclude/include C code but you do not mention how it's important. The information too vague to recommend alternatives. Maybe a C++ object would eliminate the need for it. Maybe a structure with callback addresses would work. > You mention I/O and TCP. Also vague as to their importance to your question. I'm guessing that you are asking how to get assembler and C working together. You seem to be saying a z/OS assembler program will call different C functions and a Windows program will call those same C functions. Or maybe you are saying you have a C program that calls different functions based on some data (where z/OS will use an assembler program to get that data). > If you didn't get the answer you need, then maybe you could restate the question. > Regards, Jon. > On Monday, July 1, 2019, 02:40:21 PM PDT, Joseph Reichman <reichman...@gmail.com> wrote: > > I have most of it written in Assembler as .a TCP/IP server > > With Windows being the client it issues command to the tcp/ip server > Each command is in a CSECT > > > In this Assembler CSECT I would like to call the C DLL to open read the file > > In Windows I would be displaying it in a rich edit > > The stream in callback would call the DLL to do the same seems like most of the code is similar besides the actual I/O > > > > >> On Jul 1, 2019, at 5:26 PM, Charles Mills <charl...@mcn.org> wrote: >> >> Can you do the whole process in C? When I first tried to move myself from >> doing everything in assembler I kept hoping to dimp my toe into doing little >> bits and pieces in C, and that never worked out. What worked out was writing >> the whole darned thing in C, and then using assembler for a few little bits >> and pieces where necessary. >> >> Something AMODE 31 C does wonderfully is dataset I/O, and does it in a way >> that is for the most part -- depending on exactly what you are trying to >> accomplish -- compatible with Windows C. >> >> Charles >> >> >> -----Original Message----- >> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] >> On Behalf Of Joseph Reichman >> Sent: Monday, July 1, 2019 2:04 PM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: C DLL Code from Assembler >> >> I am trying to read a VB file >> >> First of my Assembler code is RMODE31 >> So I anyway have to call something below the line to open to read to close >> so each of these could be a DLL export >> >> The Z/os data I hope to save in a data space >> The windows in the global heap >> >> The processing is similar outside of the I/O >> Can I use Metal C for this >> >> >> Thanks >> >> >> >> >>> On Jul 1, 2019, at 4:56 PM, Charles Mills <charl...@mcn.org> wrote: >>> >>> I have written a bunch of Z and Windows "system" software in C++ so I >> think >>> I am qualified to answer this question. >>> >>> I don't think I know enough to judge the overall practicality of this >>> approach. Some things are nearly identical on Z and Windows: TCP comes to >>> mind. Some things are radically different: panel-based user interface >> comes >>> to mind. >>> >>> I am not crazy about #ifdef's. I am a C outlier in that regard. I use >> #ifdef >>> where I have to but prefer (a.) two different libraries with common >>> functionality and prototypes; and (b.) a run-time switch (assuming the >>> bypassed code compiles on both machines and providing the code path is not >>> super time-critical). >>> >>> I would not preclude the use of "real" (LE) C. One could argue that it is >>> Metal C that has no equivalent on Windows. The equivalents of the services >>> of LE are available from the Windows runtime and OS. Whether it is >> "doable" >>> without LE would depend on what functionality you are trying to >> accomplish. >>> >>> Charles >>> >>> >>> -----Original Message----- >>> From: IBM Mainframe Assembler List >> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] >>> On Behalf Of Joseph Reichman >>> Sent: Monday, July 1, 2019 1:25 PM >>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >>> Subject: C DLL Code from Assembler >>> >>> Hi >>> >>> >>> >>> I have some code the majority of which I would like to duplicate on a >>> Windows platform. It occurred to me that if I write the code as a C/C++ >>> DLL the changes most of which I can segregate with a #ifdef. >>> >>> Is this doable using Metal C or do I have to use language environment. I >> am >>> looking to call the DLL entry points from assembler >>> >>> >>> >>> Thanks
