Hi guys

During migration the DLL records in SYSPROCS get renamed e.g. DLL_USER32 becomes DLL_USER32_MIGRATED*ORYX (where ORYX is the account I'm reviewing). We saw this because we call DisableProcessWindowsGhosting in our login routine and obviously it's not where it was previously under 9.x.

Is it a matter of working out which calls are still relevant, then locating the relevant 64bit DLL and doing a DECLARE_FCNS to prototype them?

Also, I can't see the old DEFINE_STRUCT form, for those DLLs that don't use basic data types - how does this work in OI 10.

Hi James,

What we've tried to do in v10 is make _everything_ an entity so it can be tracked properly. For DLL prototype records this means that there is now a DLLPROTOTYPE repository type and a specific tool (aka "Designer" ) to edit it. So, you can open up a DLL prototype record in the IDE by using Alt-O just like any other entity, or create a new one with Ctrl-N.

When you're in there you'll see where you can edit the functions and their argument types along with a much wider range of variable type options that hopefully should help. You can also easily apply an alias prefix to the function name (recommended). You don't have to use DECLARE_FCNS - from this tool just hit F9 to "compile", which does the work of DECLARE_FCNS for you.

(Of course, if you want to edit the raw records and use DECLARE_FCNS then you can do that too)

One of the big problems over the years is that _everyone_ edits DLL_USER32, DLL_KERNEL32 etc and it gets really messy for upgrading, so for v10 we moved all of Rev's DLL prototype code into an "MSWIN_" namepsace (using the alias prefix) and then claimed that as "ours". So you can still use the old prototype records if you wish - future Rev upgrades won't touch them, but if you change anything in an "RTI_" or "MSWIN_" record then we reserve the right to overwrite your changes :)

Is it a matter of working out which calls are still relevant, then locating the relevant 64bit DLL and doing a DECLARE_FCNS to prototype them?

Yes, though to be fair this shouldn't be a big change as _most_ data types are the same. E,g, a HANDLE is the same in v9 and v10, and LPWSTR is the same etc. What you usually have to watch out for is integer types that are a specific width, so there are now 64-bit types in case you need those. If you see anything you're not not sure about just post it up on here and we can take a look.

Also, I can't see the old DEFINE_STRUCT form, for those DLLs that don't use basic data types - how does this work in OI 10.

C-Structs are the same principle - they are just DLLSTRUCT type entities and have their own tool.

Carl Pates

Thanks Carl.

Agree with the entity concept. All sounds good, will check the rest out in the next few weeks.

Will also checkout DLLSTRUCT - just haven't needed to before.

Well done to you and the team on the conversion!

Hi Carl

I manually added a prototype for USER32 → GetLastInputInfo, compiled and all good - thanks for that.

I checked the USER32_ORYX_MIGRATED DLL prototype record and it already had 2 prototype definitions:

MonitorFromRect

GetMonitorInfoA

.. which we didn't create. All of the other prototype calls weren't listed, do these need to be recreated manually? Full list from 9.x below:

USER32

UINT STDCALL ArrangeIconicWindows(HANDLE)

INT STDCALL BringWindowToTop(HANDLE)

INT STDCALL EnumWindows(CALLBACK, VARIABLE)

HANDLE STDCALL FindWindowA(LPCHAR,LPVOID) as FindWindow

SHORT STDCALL GetAsyncKeyState(INT)

VOID STDCALL GetClientRect(HANDLE, LPCHAR)

VOID STDCALL GetCursorPos(LPCHAR)

HANDLE STDCALL GetDC(HANDLE)

HANDLE STDCALL GetFocus(VOID)

SHORT STDCALL GetKeyState(INT)

HANDLE STDCALL GetMenu(HANDLE)

ULONG STDCALL GetSysColor(INT)

HANDLE STDCALL GetSystemMenu(HANDLE, INT)

INT STDCALL GetSystemMetrics(INT)

HANDLE STDCALL GetWindow(HANDLE,UINT)

INT STDCALL GetWindowLongA(HANDLE, INT) as GetWindowLong

VOID STDCALL GetWindowRect(HANDLE, LPCHAR)

INT STDCALL MessageBeep(UINT)

INT STDCALL MessageBox(HANDLE,LPCHAR,LPCHAR,UINT)

INT STDCALL IsIconic(HANDLE)

INT STDCALL IsWindow(HANDLE)

INT STDCALL IsWindowVisible(HANDLE)

LONG STDCALL PostMessageA(HANDLE,UINT,UINT,LONG) as PostMessage

UINT STDCALL RegisterWindowMessageA(LPCHAR) as REGISTERWINDOWMESSAGE

INT STDCALL ReleaseDC(HANDLE,HANDLE)

HANDLE STDCALL ScreenToClient(HANDLE, LPCHAR)

LONG STDCALL SendMessageA(HANDLE,UINT,UINT,LONG) as SendMessage

HANDLE STDCALL SetFocus(HANDLE)

INT STDCALL ShowWindow(HANDLE,INT)

INT STDCALL SystemParametersInfoA( UINT, UINT, LPCHAR, UINT ) as winAPI_SystemParametersInfo

INT STDCALL SystemParametersInfoA( UINT, UINT, UINT, UINT ) as winAPI_SystemParametersInfoByPtr

UINT STDCALL DisableProcessWindowsGhosting( VOID )

UINT STDCALL GetLastInputInfo(LPBINARY)

Hi James,

The migration process brings across all "DLL_" records in SYSPROCS that aren't Revelation-specific ones - i.e if they're in this list then they get ignored:

equ IGNORE_DLLS$ to "APPDLG,CREVEXT,DIRECTPRINT,KERNEL,LH,LZFUNCS,MSG,NWCALLS," |

                    :  "OENGINE,OI2MAPI,OI2NOTES,OI30DSXO,OICOMMON,OIPI_KERNEL,"   |

                    :  "OIPI_USER32,OISTRCNV,OLE32,PRINTER,RDKSUPP,REVCOMI_USE,"   |

                    :  "REVDEBUG,REVDSXO,REVLHVA,RTP65,SHELL,TAB95,THUNKING,USER," |

                    :  "UTF8,V119"

Anything else is copied across with a suffix of "_MIGRATED" and then marked for evaluation - it's then up to you what you do with them (they are not compiled) - here's the code from the migration proc:

   loop

      readNext sysProcsID else eof = TRUE$

   until eof



      ctr += 1

      

      if ( sysProcsID[1,4] == "DLL_" ) then

         // Assume it's a DLL record ...

         if ( sysProcsID[1,10] = "DLL_MSWIN_" ) then

            // Ignore - this is a Rev one ...

            resultText = "Skipping " : quote( sysProcsID ) : " DLL Prototype record (System Component)"

            goSub updateResults_OK

         end else

            locate sysProcsID[5,\00\] in IGNORE_DLLS$ using "," setting pos then

               resultText = "Skipping " : quote( sysProcsID ) : " DLL Prototype record (deprecated)"

               goSub updateResults_OK

            end else

               // Bring it in ...

               read dllRec from fhSysprocsTemp@, sysProcsID then



                  // Suffix it so we don't collide with anything

                  sysProcsID := "_MIGRATED"



                  // param1  -> state

                  // param2  -> publish

                  // param3  -> share

                  // param4  -> super

                  // param5  -> sub

                  // param6  -> document

                  // param7  -> accessPermit

                  // param8  -> updatePermit

                  // param9  -> title

                  // param10 -> DLL Prototype Record



                  reposID  = M_APPID$ : "*DLLPROTOTYPE**" :  sysProcsID[5,\00\]



                  rState   = ""

                  rPublish = TRUE$

                  rShare   = TRUE$

                  rSuper   = ""

                  rSub     = ""

                  rDoc     = ""

                  rAccess  = "$PUBLIC"

                  rUpdate  = "$PUBLIC"

                  rTitle   = "Migrated DLL Prototype Record"



                  call repository( "WRITE", reposID, rState, rPublish, rShare, rSuper, rSub, rDoc, rAccess, rUpdate, rTitle, dllRec )

                  if get_Status( errorText ) then

                     call set_Status( SETSTAT_OK$ )

                     errorText = "Error writing " : quote( reposID ) : " [" |

                           : rti_ErrorText( "SP", errorText ) : "]"

                     goSub updateResults_Error; errorText = ""; bDLLError = TRUE$

                  end else

                     dllIDs<-1> = reposID

                     resultText = "Imported " : quote( sysProcsID ) : " DLL Prototype record OK"

                     goSub updateResults_OK



                     // One last thing - mark the item for Evaluation

                     reposRec = repository( "GET", reposID )

                     if get_Status( errorText ) then

                        // Don't care ...

                     end else

                        reposRec<SYSREP_EVALUATE$>   = TRUE$

                        reposRec<SYSREP_EVAL_NOTES$> = "Migrated from v9 - please review"

                        call repository( "SET", reposID, reposRec )

                     end



                     call set_Status( SETSTAT_OK$ )

                  end



               end else

                  errorText = "Error reading " : quote( sysProcsID ) : " from the remote SYSPROCS table [" |

                        : rti_ErrorText( "FS", @file_Error ) : "]"

                  goSub updateResults_Error; errorText = ""; bDLLError = TRUE$

               end

            end

         end

      end



   while not( abort )

      goSub isCancelMigration

   while not( bCancel )

   repeat

…do these need to be recreated manually?

You don't need to add anything you don't actually use (You could also switch to using the MSWIN_ versions if you wish - I guess that depends on how many API calls you're using).

As I said before the reason we have to leave this down to you is that everyone has different copies of the same core DLL prototype records, so rather than break someone's application we moved our DLL prototypes to a known namespace leaving other systems intact to be handled by the people who knew them best :)

Regards

Carl Pates

Hi James,

One other thing - you mention the Windows API "DisableProcessWindowsGhosting" function. There's a SYSTEM object method that handles this for you if you want to use it in v10:

   // Turn off Window Ghosting for the rest of the session

   Call Set_Property_Only ( "SYSTEM", "WINDOWGHOSTING", FALSE$ )

These remarks are from the SYSTEM docs:

"Window Ghosting" is a system function that Windows initiates when it thinks that a process has become unresponsive, typically because it gets involves in a long, time-consuming operation and doesn't check its message queue periodically by calling the Yield function. When this happens, Windows adds a "Not Responding" message to the form's caption, but unfortunately this can appear to end users to be an error condition. It also allows the user to move or close the form as well, which could lead to other problems. The ideal way to deal with this situation is to refactor long operations in the application so that they call the Yield function periodically (every few seconds at least) so Windows is notified that the Presentation Server has not crashed or run into an infinite loop. If this cannot be done the WINDOWGHOSTING property can be set to FALSE$ to stop the "Not Responding" behavior. However, in this case the user won't be able to minimize, move, or close the main window of the application if it is actually not responding due to an error condition and they will have to use the Task Manager to close it instead - this may give the impression that the application is unstable! This method is essentially a wrapper around the DisableProcessWindowsGhosting Windows API function - for further information please see the Microsoft website.

Regards,

Carl Pates

Thanks for all the info Carl

We actually don't use a heap of native dll calls from OI, but of course a few important areas, at least under 9.x and I'm happy to test these and sort out.

I get that everyone does things slightly differently - one of the great and I am sure annoying things I am guessing from a conversion point of view is how flexible the Rev environment is.

Thanks Carl

View this thread on the Works forum...