[Bug 52131] New: wine-mono + RMS Express: HF Channel Selection Browser crashes
https://bugs.winehq.org/show_bug.cgi?id=52131 Bug ID: 52131 Summary: wine-mono + RMS Express: HF Channel Selection Browser crashes Product: Wine Version: 6.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: eric.wheez(a)gmail.com Distribution: --- wine-mono + RMS Express: HF Channel Selection Browser crashes when updating from the internet (crashes soon after the "Update from Internet" button is pushed - after downloading data, during "STANDBY - Updating RMS channels propagation indices for" [callsignhere]). Crash happens with wine-mono, but does not happen with dotnet46. A very similar-looking crash also happens when pushing the "SFI" (solar flux index) button in the HF Channel Selection Browser (which also crashes during "STANDBY - Updating RMS channels propagation indices for" [callsignhere]). This crash could be the same crash as the "Update from Internet" crash. Notes: Madewokherd (Esme) has been incredibly gracious (already fixing three other errors in wine-mono + RMS Express) that I didn't want to be annoying by posting another RMS Express error on their github page, so I thought maybe this would be the best place to post. The other bugs that Esme fixed (thank you!!) and their terminal logs (for comparison) can be found here: https://github.com/madewokherd/wine-mono/issues/116 & https://github.com/madewokherd/wine-mono/issues/122 System specs: - Program: RMS Express.exe (Winlink Express) v1.5.42.0 (latest as of 11/28/2021 - downloaded from https://downloads.winlink.org/User%20Programs/ ). Note: This program requires a free user account to use. User accounts can be created for free using the in-program prompts on first-run. - Winetricks packages: winetricks -q dotnet46 win7 sound=alsa - Wine version: wine-devel 6.22 - wine-mono version: Nov 26, 2021 nightly (PR #126 / commit 6831b18 - msi downloaded from https://github.com/madewokherd/wine-mono/actions/runs/1496716432 ) - OS: x86 Debian 10 Linux (on VMWare Workstation 16 on a Windows laptop) Logs: I've logged quite a bit of behavior and attached those below. - For larger logs, I've included truncated versions and 'interesting' parts. - The crash 'backtrace' from the wine/wine-mono "Program Error" window is included. - Logs also include both the program running idly in wine-mono (without pushing the "Update from Internet" button) and the program crash in wine-mono. - Different logs were made using by running wine-mono's built-in functions: WINE_MONO_TRACE=x, WINE_MONO_TRACE=program, and WINE_MONO_TRACE=wrapper. (No suspicious WINE_MONO_TRACE=x exceptions pop up during the crash though). - I've also logged normal behavior on Windows using "Improved dotNET Tracer" (by Kao / Kurapica), which shows which program VB.NET methods are supposed to be being used when the crash happens (it also doesn't expose any .NET Windows/Winlink code internals, just program method names near the crash). - Some pictures are also included for reference. Let me know what you think or if I can submit any other logs. And thank you for reading/considering it! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #1 from Eric <eric.wheez(a)gmail.com> --- Created attachment 71167 --> https://bugs.winehq.org/attachment.cgi?id=71167 Most of the HF Channel Selection Browser crash logs (minus the wrapper log due to file size limit) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #2 from Eric <eric.wheez(a)gmail.com> --- Created attachment 71168 --> https://bugs.winehq.org/attachment.cgi?id=71168 Truncated version of the wine-mono wrapper log during crash (relevant section of log only due to file size limit) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #3 from Eric <eric.wheez(a)gmail.com> --- Going through the truncated wrapper log: Searching for "STANDBY - Updating RMS channels propagation indices for" finds that the last callsign processed (multiple times) is "9W2RUT", but the callsign processed right before that (also processed multiple times) is "8P6BWS". The channel browser freezes while displaying 8P6BWS when the crash happens. So I think that the truncated log is capturing everything and the crash probably happens near "STANDBY - Updating RMS channels propagation indices for 9W2RUT" in the wrapper log. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #4 from Eric <eric.wheez(a)gmail.com> --- And just a bit more info from logging methods on Windows with Improved dotNET Tracer (expected behavior): On Windows (expected behavior) - methods that run after pushing the "SFI" button: WinlinkInterop.WinlinkInterop.GetSSN WinlinkInterop.WinlinkInterop.GetPredictSSN WinlinkInterop.WinlinkInterop.SFItoSSN RMS_Express.Propagation.RefreshPathQuality [Load PropagationPrediction.dll] PropagationPrediction.PredictionClass.LoadDll RMS_Express.Propagation.GetPathQualityIndicesFast PropagationPrediction.PredictionClass.PredictPropagation PropagationPrediction.PredictionClass.RangeAndBearing PropagationPrediction.PredictionClass.GredSquareToLatitudeLongitude PropagationPrediction.PredictionClass.ValidateGridSquare PropagationPrediction.PredictionClass.CreateDVOACapQuery PropagationPrediction.PredictionClass.GridSquareToDecimalDegrees RMS_Express.Propagation.CheckHours System.Runtime.InteropServices.SEHException -> PropagationPrediction.PredictionClass.PredictPropagation PropagationPrediction.PredictionClass.UnloadDll RMS_Express.INIFile.WriteInteger [no more methods run] On Windows (expected behavior) - methods that run after pushing the "Update Via Internet" button: RMS_Express.HFChannelSelector.mnuUpdate_Click RMS_Express.HFChannelSelector.UpdateChannels RMS_Express.HFChannelSelector.GetHFChannelRecords RMS_Express.Globals.GetChannelsList RMS_Express.Globals.GetChannelsThread WinlinkInterop.WinlinkInterop.GatewayChannelReport WinlinkInterop.JsonEnum.Convert RMS_Express.Globals.UpdateMPSListViaInternet RMS_Express.Globals.GetHybridRMSList RMS_Express.Globals.GetAllNetworkParameters WinlinkInterop.WinlinkInterop.GetAllNetworkParameters System.Runtime.InteropServices.SEHException -> PropagationPrediction.PredictionClass.PredictPropagation [paused since the progress of the is now beyond where it crashes in wine-mono] -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #5 from Eric <eric.wheez(a)gmail.com> --- Edit to my last comment: The `On Windows (expected behavior) - methods that run after pushing the "Update Via Internet" button:` log should actually read as... RMS_Express.HFChannelSelector.mnuUpdate_Click RMS_Express.HFChannelSelector.UpdateChannels RMS_Express.HFChannelSelector.SaveSortOrder RMS_Express.HFChannelSelector.GetHFChannelRecords WinlinkInterop.Enumerations..cctor RMS_Express.Globals.GetChannelsList RMS_Express.Globals.GetChannelsThread WinlinkInterop.WinlinkInterop.GatewayChannelReport WinlinkInterop.JsonEnum.Convert WinlinkServiceClasses.GatewayChannelReportResponse..ctor RMS_Express.Globals.UpdateMPSListViaInternet RMS_Express.Globals.GetHybridRMSList RMS_Express.Globals.GetAllNetworkParameters WinlinkInterop.WinlinkInterop.GetAllNetworkParameters WinlinkServiceClasses.RadioNetworkParamsListResponse..ctor RMS_Express.Propagation..ctor WinlinkInterop.WinlinkInterop.GetSSN WinlinkInterop.WinlinkInterop.GetPredictedSSN WinlinkInterop.WinlinkInterop..cctor WinlinkInterop.WinlinkInterop.SFItoSSN RMS_Express.Propagation.RefreshPathQuality [Load PropagationPrediction.dll] PropagationPrediction.PredictionClass..ctor PropagationPrediction.PredictionClass.LoadDll RMS_Express.Propagation.GetPathQualityIndicesFast PropagationPrediction.PredictionClass.PredictPropagation PropagationPrediction.PredictionClass.RangeAndBearing PropagationPrediction.PredictionClass.GridSquareToLatitudeLongitude PropagationPrediction.PredictionClass.ValidateGridSquare PropagationPrediction.PredictionClass.CreateDVOACapQuery PropagationPrediction.PredictionClass.GridSquareToDecimalDegrees RMS_Express.Propagation.CheckHours System.Runtime.InteropServices.SEHException -> PropagationPrediction.PredictionClass.PredictPropagation PropagationPrediction.PredictionClass.UnloadDll RMS_Express.INIFile.WriteInteger I just realized I wasn't using Improved dotNET Tracer quite right for that section. I also didn't report the .ctor and .cctor methods in the other section. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #6 from Eric <eric.wheez(a)gmail.com> --- Last tidbit for now: I just wanted to double-check `WINE_MONO_TRACE=E:System.ArgumentException,E:System.NullReferenceException MONO_INLINELIMIT=0 WINE_MONO_HIDETYPES=1 wine RMS\ Express.exe` and I now believe even more that they're probably not related to the HF Channel Selection Browser update crash. These exceptions appear to be coming from the ARDOP_Win.exe that runs alongside RMS Express.exe occasionally. They also only appear in the terminal _before_ I push the HF Channel Selection Browser's "Update from Internet" or "SFI" buttons. Also, the HF Channel Selection Browser shouldn't interact with ARDOP_Wine.exe at all, to my knowledge. I'll post these exceptions as an attachment too. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #7 from Eric <eric.wheez(a)gmail.com> --- Created attachment 71173 --> https://bugs.winehq.org/attachment.cgi?id=71173 wine-mono trace of selected exceptions -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #8 from Eric <eric.wheez(a)gmail.com> --- Another clue: I renamed ".../RMS\ Express/PropagationPrediction.dll" to "xPropagationPrediction.dll" and then pressed RMS Express's HF Channel Selector's "Update Via Internet" button, which would normally crash (I was unable to test the "SFI" button). The HF Channel Selector downloads info from the internet and then hangs on "Updating propagation estimates..." but doesn't crash. So, I think that the crash must happen in a method within PropagationPrediction.dll or soon after that. Therefore, I believe the crash must happen within one of these methods (which we learned from the Windows traces are attempted to be run after pushing either the "SFI" or "Update Via Internet" buttons): [Load PropagationPrediction.dll] PropagationPrediction.PredictionClass..ctor PropagationPrediction.PredictionClass.LoadDll RMS_Express.Propagation.GetPathQualityIndicesFast PropagationPrediction.PredictionClass.PredictPropagation PropagationPrediction.PredictionClass.RangeAndBearing PropagationPrediction.PredictionClass.GridSquareToLatitudeLongitude PropagationPrediction.PredictionClass.ValidateGridSquare PropagationPrediction.PredictionClass.CreateDVOACapQuery PropagationPrediction.PredictionClass.GridSquareToDecimalDegrees RMS_Express.Propagation.CheckHours System.Runtime.InteropServices.SEHException -> PropagationPrediction.PredictionClass.PredictPropagation PropagationPrediction.PredictionClass.UnloadDll RMS_Express.INIFile.WriteInteger I'm wondering if the System.Runtime.InteropServices.SEHException that pops up when tracing on Windows might be the problem? Maybe it's some less elegantly-implemented code which dotnet skirts around but which throws a wrench into the works for wine-mono? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #9 from Eric <eric.wheez(a)gmail.com> --- Also wanted to say that I just realized in my Comment 4 above, "GredSquareToLatitudeLongitude" (instead of "GridSquareToLatitudeLongitude") is my typo, not the program's typo (I was copying the method names by hand to make the log) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #10 from Eric <eric.wheez(a)gmail.com> --- Ok, so, the "WINE_MONO_TRACE=program" log seems to indicate the crash is happening somewhere soon after "RMS_Express.Propagation:GetPathQualityIndicesFast" is called and before the program returns from that method (since we don't see that method returning). The Improved dotNET Tracer (on Windows) log indicates that PropagationPrediction.dll is called for the first time right after RMS_Express.Propagation:GetPathQualityIndicesFast , so I'm guessing that RMS_Express.Propagation:GetPathQualityIndicesFast calls methods within PropagationPrediction.dll. To trace methods within PropagationPrediction.dll, I ran `WINE_MONO_TRACE=N:PropagationPrediction wine RMS\ Express.exe 2>&1 | tee namespacepropagation1.log` and found that the crash happens right after leaving PropagationPrediction.PredictionClass:CreateDVOACapQuery. The program enters and leaves this method many other times previously without problems, however (though this is the only instance when "RxLocations" Lat is only 3 digits and the only instance when Lon is 5 digits?). The backtrace does mention "dvoa", which looks like CreateDVOACapQuery(?) --- snip --- 0 0x7b010013 RaiseException+0x8e(code=<couldn't compute location>, flags=<couldn't compute location>, count=<couldn't compute location>, args=<couldn't compute location>) [Z:\usr\src\packages\BUILD\dlls\kernelbase\debug.c:302] in kernelbase (0x0021cee8) 1 0x1279c9c2 Predict+0x1be() in dvoa (0x0021d698) --- snip --- I'll attach the namespace log and its corresponding backtrace too. Other tidbits: - "DN06UB", is my "home gridsquare location", which approximately locates my old apartment near Walla Walla, WA. - My home gridsquare seems to be compared with other another gridsquare locations (probably winlink 'gateway' radio stations). - Right before the crash, "DN06UB" is compared with "OJ02UX" (which is somewhere in Kajang, Malaysia and has that different-looking lat/long). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #11 from Eric <eric.wheez(a)gmail.com> --- Created attachment 71193 --> https://bugs.winehq.org/attachment.cgi?id=71193 WINE_MONO_TRACE=N:PropagationPrediction wine RMS\ Express.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #12 from Eric <eric.wheez(a)gmail.com> --- I found a dvoa.dll in the main `RMS\ Express` directory. When I rename it to "xdvoa.dll" and run RMS Express, I can press the SFI button and not have the program crash (though RMS Express does warn "C:\RMS Express\dvoa.dll not found. No propagation data will be available." and the "Path Reliability Estimate" and "Path Quality Estimate" cells in the HF Channel Selector window turn all to 0's). PEiD shows dvoa.dll to be a "Borland Delphi DLL". I've so far been unsuccessful trying to trace dvoa.dll in wine-mono. Opening it in notepad++ and looking for text strings, I found "TVoacapEngine", which I believe is a reference to the "Voice of America Coverage Analysis Program", a free professional high-frequency (HF) propagation prediction software https://www.voacap.com/ So, I currently think that RMS Express might be sending data to this library to have it calculate propagation prediction information, then send that info back to RMS Express. Maybe something is getting messed up with how data is sent or received to/from that library? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #13 from Eric <eric.wheez(a)gmail.com> --- Going back to the backtrace, "Unhandled exception: 0x0eedfade in 32-bit code (0x7b010013).", it appears that "0eedfade" may be the code for a Delphi exception according to: https://codeverge.com/embarcadero.delphi.nativeapi/-unknown-exception-code-0... I'm wondering if wine-mono is feeding a somehow unexpected into to dvoa.dll and dvoa.dll is reporting an error? I'm not sure how to test inputting other lat/longs into dvoa.dll via wine-mono yet, but I'm wondering if the two spaces after "Lat": in `"Lat": 2.98, "Lon": 101.71,` could be part of the problem? All other working Lat/Long inputs have one space after "Lat": object:__icall_wrapper_mono_string_to_ansistr may also be something to check, though I'm not sure how to do that yet. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #14 from Eric <eric.wheez(a)gmail.com> --- I found this stackoverflow post that seems relevant: https://stackoverflow.com/questions/16602756/strange-0x0eedfade-exception-in... "After some debugging that lead me to nowhere (Call Stack with very strange places) I resigned from it and started to inspect lastly commited changes. One change was string operation where string (AnsiString) can be of length 64 or 128 (some kind of bit mask). I set 70th character of string that was earlier allocated with SetLength(buffer, 64). That was the problem. I think I would save time by enabling range checking." -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #15 from Eric <eric.wheez(a)gmail.com> --- I figured out that the OJ02UX gridsquare is definitely causing the problem in some way: - I found a file called `C:\RMS Express\KI7POL\Data\RMS Channels.dat` that contains channels that are downloaded from the internet (when pressing the "Update from Internet" button) and then later calculated for propagation quality. - Pressing the "SFI" button seems to not download a new `RMS Channels.dat` file and just calculate propagation quality from the .dat file. - If I delete this line in the .dat file `9W2RUT|OJ02UX|7093|41|00-23|PUBLIC` then RMS Express doesn't crash with wine-mono when pushing the "SFI" button. - If I replace OJ02UX with a different gridsquare (so that it looks like: 9W2RUT|DN06UB|7093|41|00-23|PUBLIC), then the crash is also averted. - If I replace 9W2RUT with a different gridsquare, but keep OJ02UX (so that it looks like: DN06UB|OJ02UX|7093|41|00-23|PUBLIC), then the crash happens again. I've discovered that 9W2RUT is a person's callsign, not a gridsquare. I'm currently crunching through some gridsquares that I made up from this map: https://en.wikipedia.org/wiki/Maidenhead_Locator_System#/media/File:Maidenhe... to see which ones crash RMS Express with wine-mono. I'm planning on comparing those `WINE_MONO_TRACE=N:PropagationPrediction` traces with the working ones to see what might be different between them, though it's taking a while. It's also possible that RMS Express might be using a calculation to convert gridsquare to lat/long and maybe something in that calculation is erroring - though that might not produce a Delphi exception error if that was the case(?) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #16 from Eric <eric.wheez(a)gmail.com> --- Created attachment 71214 --> https://bugs.winehq.org/attachment.cgi?id=71214 Analysis of crashing vs working gridsquares given to PropagationPrediction.dll/dvoa.dll It looks like the crashing gridsquares all have a returning value of `"Freqs": [ 0.01]` but the working gridsquares have a returning value of "Freqs" with other values. Here's an example with oversimplified text: --Working-- ENTER:c ([STRING:030c77c0:IM59NE], 3610.100000, [:031aee58]) LEAVE:c ([STRING:03000760:{"Arguments": {"RxLocations": [{"Lat": 39.19, "Lon": -8.88, "Freqs": [ 3.61] -------- --Crashing-- ENTER:c ([STRING:03249260:AE01UB], 7.093000, [:03249058]) LEAVE:c ([STRING:0324ba20:{"Arguments": {"RxLocations": [{"Lat": -48.94, "Lon": -178.29, "Freqs": [ 0.01] -------- RMS Channels.dat CT1CPS|IM59NE|3610100|13|00-23|PUBLIC <-- working CT1CPS|IM59NE|3610100|50|00-23|PUBLIC <-- working DA5UDI|JO30QJ|7051400|43|00-23|PUBLIC <-- working 9W2RUT|AE01UB|7093|41|00-23|PUBLIC <-- crashes 9W2RUT|OJ02UX|7093|41|00-23|PUBLIC <-- crashes | | | | | |__HF frequency to calculate propagation qualty for | | | |__Gridsquare (geographical location) | |__Callsign (person) I'm attaching more examples of this kind of analysis with oversimplified strings for easier comparison (I just found/replaced a lot of the parts that were the same between all the strings so things would be easier to read) So, now I'm thinking that it may not be the Lat/Long input, but the frequency input that is the issue. I think the PropagationPrediction.PredictionClass:CreateDVOACapQuery method may be garbling just some of the input frequency strings that are supposed be sent to dvoa.dll (I believe dvoa.dll is run during the LoadDll method) and then dvoa.dll is reporting an error with 0x0eedfade. I'm not sure why only some smaller-value frequencies would cause issues, but I'll keep digging. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #17 from Eric <eric.wheez(a)gmail.com> --- Also, regarding my observation above: "If I replace OJ02UX with a different gridsquare (so that it looks like: 9W2RUT|DN06UB|7093|41|00-23|PUBLIC), then the crash is also averted." Tracing the PropagationPrediction namespace, it appears that if I put my own gridquare in there to calculate prediction for, RMS Express appears to ignore the calculation of prediction, so that might be why I was able to avoid the crash by doing that in that case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #18 from Eric <eric.wheez(a)gmail.com> --- Hm, going back to the wrapper crash log: Comparing a working gridsquare/freq to the broken one again, it looks like often the first time a grid/freq result from PropagationPrediction.CreateDVOACapQuery comes back, the next thing happens is a giant table like this usually appears. --- snip --- ... [00000024: 681.92182 19] ENTER:c (wrapper managed-to-native) object:wrapper_native_16c5c804 (string)([STRING:0332a3a8:{"Arguments": {"RxLocations": [{"Lat": 13.15, "Lon": -59.63, "Label": "Receiver"}],"Hours": {"Start": 1, "Step": 1, "Count": 24},"Freqs": [14.12],"IncludeMuf": true},"Params": { "RequiredReliability": 0.9, "MultipathPowerTolerance": 3, "Ssn": 27.6705965542631, "MinAngle": 5.0, "ManMadeNoiseAt3MHz": 143, "LongPath": false, "Month": 11, "RequiredSnr": 40.0, "MaxTolerableDelay": 0.00, "TxLoc": {"Lat": 46.06, "Lon": -118.29, "Label": "Transmitter"}, "TxPower": 50.0000},"Outputs": [ "SNR", "REL"],"OutputFormat": "voa"}]) [00000024: 681.92185 20] ENTER:c (wrapper managed-to-native) object:__icall_wrapper_mono_string_to_ansistr (object)([STRING:0332a3a8:{"Arguments": {"RxLocations": [{"Lat": 13.15, "Lon": -59.63, "Label": "Receiver"}],"Hours": {"Start": 1, "Step": 1, "Count": 24},"Freqs": [14.12],"IncludeMuf": true},"Params": { "RequiredReliability": 0.9, "MultipathPowerTolerance": 3, "Ssn": 27.6705965542631, "MinAngle": 5.0, "ManMadeNoiseAt3MHz": 143, "LongPath": false, "Month": 11, "RequiredSnr": 40.0, "MaxTolerableDelay": 0.00, "TxLoc": {"Lat": 46.06, "Lon": -118.29, "Label": "Transmitter"}, "TxPower": 50.0000},"Outputs": [ "SNR", "REL"],"OutputFormat": "voa"}]) [00000024: 681.92188 20] LEAVE:c (wrapper managed-to-native) object:__icall_wrapper_mono_string_to_ansistr (object)(result=002ab460 [00000024: 681.93315 20] ENTER:c (wrapper managed-to-native) object:__icall_wrapper_mono_marshal_free (intptr)(002ab460) [00000024: 681.93734 20] LEAVE:c (wrapper managed-to-native) object:__icall_wrapper_mono_marshal_free (intptr)( [00000024: 681.93744 19] LEAVE:c (wrapper managed-to-native) object:wrapper_native_16c5c804 (string)(result=175e03ac [00000024: 681.93752 19] ENTER:c (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:PtrToStringAnsi (intptr)(175e03ac) [00000024: 681.93762 19] LEAVE:c (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:PtrToStringAnsi (intptr)([STRING:11701350: 46.06 N 118.29 W - 13.15 N 59.63 W 1.0 10.9 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -3 -60 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 2.0 11.2 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -2 -62 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 3.0 9.8 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 4 -132 - - - - - - - - - - SNR 0.03 0.00 - - - - - - - - - - REL 4.0 9.1 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -4 -182 - - - - - - - - - - SNR 0.01 0.00 - - - - - - - - - - REL 5.0 9.1 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -3 -220 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 6.0 9.6 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -2 -178 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 7.0 10.2 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -1 -128 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 8.0 10.7 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 0 -99 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 9.0 9.7 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -2 -128 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 10.0 9.3 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -2 -236 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 11.0 8.5 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -4 -323 - - - - - - - - - - SNR 0.01 0.00 - - - - - - - - - - REL 12.0 9.5 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -5 -211 - - - - - - - - - - SNR 0.01 0.00 - - - - - - - - - - REL 13.0 12.8 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 3 -31 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 14.0 17.0 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 8 16 - - - - - - - - - - SNR 0.03 0.00 - - - - - - - - - - REL 15.0 20.6 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 7 10 - - - - - - - - - - SNR 0.03 0.00 - - - - - - - - - - REL 16.0 22.5 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 7 4 - - - - - - - - - - SNR 0.03 0.00 - - - - - - - - - - REL 17.0 23.8 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 6 2 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 18.0 23.8 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 7 -4 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 19.0 23.1 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 10 0 - - - - - - - - - - SNR 0.02 0.00 - - - - - - - - - - REL 20.0 22.7 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 12 11 - - - - - - - - - - SNR 0.04 0.00 - - - - - - - - - - REL 21.0 21.9 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 13 17 - - - - - - - - - - SNR 0.04 0.00 - - - - - - - - - - REL 22.0 19.3 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 11 21 - - - - - - - - - - SNR 0.04 0.00 - - - - - - - - - - REL 23.0 15.5 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ -2 17 - - - - - - - - - - SNR 0.02 0.01 - - - - - - - - - - REL 24.0 12.4 14.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 FREQ 3 -24 - - - - - - - - - - SNR 0.03 0.00 - - - - - - - - - - REL ] [00000024: 681.94248 19] ENTER:c (wrapper managed-to-native) object:__icall_wrapper_ves_icall_object_new_specific (intptr)(054f9e88) --- snip --- Maybe these xx.x digit table entries don't know how to process a 0.01 freq entry with wine-mono methods? Not super sure about that though -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #19 from Eric <eric.wheez(a)gmail.com> --- Alright, definitely confirmed that the crash is coming from some kind of problem parsing small value frequency inputs. First, I ran all of my 'made-up' grid squares but this time with a frequency input of 7093000 (instead of 7093) and they all worked instead of all crashing this time, so lat/long is definately not a problem (my made-up gridsquares go over the entire map). Then, I ran the same gridsquare with smaller and smaller frequencies until I made RMS Express crash. 9W2RUT|AE01UB|709300|41|00-23|PUBLIC <-- working: "Freqs": [ 0.71] 9W2RUT|AE01UB|70930|41|00-23|PUBLIC <-- working: "Freqs": [ 0.07] 9W2RUT|AE01UB|7093|41|00-23|PUBLIC <-- crashes: "Freqs": [ 0.01] Then, zero'd in on the minimum input frequency that RMS Express will accept with wine-mono: First sweep: 9W2RUT|AE01UB|70000|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|69999|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|60000|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|59999|41|00-23|PUBLIC <-- working: [STRING:032b56e8:AE01UB], 59.999000; "Freqs": [ 0.06] 9W2RUT|AE01UB|50000|41|00-23|PUBLIC <-- crashes: [STRING:032bb0a0:AE01UB], 50.000000; "Freqs": [ 0.05] 9W2RUT|AE01UB|40000|41|00-23|PUBLIC <-- crashes: "Freqs": [ 0.04] 9W2RUT|AE01UB|30000|41|00-23|PUBLIC <-- crashes: "Freqs": [ 0.03] 9W2RUT|AE01UB|20000|41|00-23|PUBLIC <-- crashes: "Freqs": [ 0.02] Getting closer: 9W2RUT|AE01UB|59000|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|58000|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|57000|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|56000|41|00-23|PUBLIC <-- working 9W2RUT|AE01UB|55000|41|00-23|PUBLIC <-- working: [STRING:032818f8:AE01UB], 55.000000; "Freqs": [ 0.06] 9W2RUT|AE01UB|54000|41|00-23|PUBLIC <-- crashes: [STRING:03287bf0:AE01UB], 54.000000; "Freqs": [ 0.05] Last test: 9W2RUT|AE01UB|54999|41|00-23|PUBLIC <-- crashes: [STRING:0323e768:AE01UB], 54.999000; "Freqs": [ 0.05] So, RMS Express crashes with wine-mono when the input frequency for PredictionClass.CreateDVOACapQuery is less than 55000 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #20 from Eric <eric.wheez(a)gmail.com> --- OK! I think I'm close: I got better at using Improved dotNET Tracer for Windows (I found the "on/off" button to specify when I want to start/stop tracing methods). I traced On a Windows computer, I traced RMS Express calculating "SFI" when... - input frequency is 55000 (which runs fine in wine-mono) - input frequency is 54000 (crashes in wine-mono). These methods pop up on Windows when input frequency is 54000 (but don't appear when input frequency is 55000): ---- snip ---- [PropagationPrediction.dll] Function compiled, GridSquareToDecimalDegrees, Module : PropagationPrediction.dll, Parent Class : PropagationPrediction.PredictionClass, Method ID : 0x844AD78, Method Token : 0600000D, CFF explorer index : 13, Exception Thrown, Exception type : System.Runtime.InteropServices.SEHException, Exception was thrown in method, Parent class : PropagationPrediction.PredictionClass, method : PredictPropagation, Method Token : 06000009, CFF explorer index : 9, [WinlinkInterop.dll] Function compiled, Finalize, Module : WinlinkInterop.dll, Parent Class : WinlinkInterop.SFIhelper, Method ID : 0x93F4D3C, Method Token : 0600002F, CFF explorer index : 47, ---- snip ---- I bet the crash isn't from wine-mono calculating small value frequencies (in PropagationPrediction.PredictionClass.CreateDVOACapQuery) any differently than on Windows. So, I think that both dotnet/Windows and wine-mono probably handle the calculation the same but some exceptions get thrown by dvoa.dll as 'normal' behavior in this case and dotnet somehow handles the exceptions, but wine-mono doesn't know how to yet. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #21 from Eric <eric.wheez(a)gmail.com> --- Minor edit: I should have said that GridSquareToDecimalDegrees is also run when calculating input frequency 55000, but doesn't throw an SEH exception. Maybe wine-mono has trouble handling the SEH Exception. Then in wine-mono, dvoa.dll, which is Delphi, throws a Delphi exception. So maybe that Delphi exception is downstream from this unhandled SEHException in PropagationPrediction.PredictionClass.GridSquareToDecimalDegrees somewhere. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #22 from Eric <eric.wheez(a)gmail.com> --- Looking at PropagationPrediction.PredictionClass.CreateDVOACapQuery in ILspy, it looks like the input frequency is first stored as a double, then PropagationPrediction.PredictionClass.GridSquareToDecimalDegrees is run (but has no frequency inputs at all), then some math and double-to-string & string-to-double conversions are run on the input frequency. I'm not actually sure if the Structured exception handling (SEH) error is with the way that the math/conversions are being handled in .NET, or if the SEH error is coming from the dvoa.dll Delphi library's erroring/exception. I suppose another thing to check would be to see where dvoa.dll came from and whether that's open-source or not. ---
From Microsoft, "Structured exception handling (SEH) is a Microsoft extension to C to handle certain exceptional code situations, such as hardware faults, gracefully." https://docs.microsoft.com/en-us/cpp/cpp/structured-exception-handling-c-cpp...
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #23 from Eric <eric.wheez(a)gmail.com> --- oh lol https://github.com/VE3NEA/DVOACAP -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #24 from Eric <eric.wheez(a)gmail.com> --- I found out that the culprit is indeed the dvoa.dll library erroring and then wine-mono not knowing how to handle the error. It seems that dotNET has a way of skirting around the condition where no data comes back from the library, but wine-mono doesn't yet. I downloaded all the files in the https://github.com/VE3NEA/DVOACAP/tree/master/DVoaDllTestCmd directory and ran the exe from DOS. An output.txt file with a table in it was created containing tables that look like this: ---snip--- 35.80 N 5.90 W - 44.90 N 20.50 E 1.0 16.2 6.1 7.2 9.7 11.9 13.7 15.4 17.7 21.6 25.9 0.0 0.0 FREQ 1F2 1F2 1F2 1F2 1F2 1F2 1F2 1F2 1F2 1F2 - - MODE 13.7 7.8 7.8 8.1 8.7 9.5 10.9 14.7 14.7 14.7 - - TANGLE 8.9 8.5 8.5 8.6 8.6 8.6 8.7 9.0 9.0 9.0 - - DELAY 440 295 296 304 317 337 371 466 466 466 - - V HITE ....keeps going ---snip--- I then changed `"Freqs":` in the `input.json` file to `[0.01]` and ran the exe from DOS again. No output.txt was created this time, but this error message appeared: ---snip--- C:\Users\AnthonyBistodeau\Desktop\Edu\dvoa>DVoaDllTestCmd.exe Exception500: Error computing prediction: Assertion failure (C:\Proj\VCL\AlProp\DVOA\DVoaClass\Reflx.pas, line 355) ---snip--- One solution might be to edit the github file to not have crashes on small frequency calculations. Another solution might be to implement an SEH exception for this kind of situation into wine-mono. A third solution might be to ask the RMS Express authors if they can make a workaround for cases when no output.txt is created from dvoa.dll. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #25 from Eric <eric.wheez(a)gmail.com> --- I'm finding some discrepancies between testing RMS Express with input freqs vs the github's dvoa.dll, but I still think that those three solutions might be the best routes: - It seems like this github's dvoa.dll has CRC-32 9E114ECB & `"Freqs": [0.062000001]` is the lowest value it will accept. - RMS Express' dvoa.dll has CRC-32 92907314 & `"Freqs": [0.054999]` is the lowest value it might accept (though it appears that RMS Express actually still passes `"Freqs": [0.05]` to dvoa.dll and it still crashes, so not sure what's going on there exactly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #26 from Eric <eric.wheez(a)gmail.com> --- Also, swapping the dvoa.dll from the RMS Express folder into the github folder and running the same DVoaDllTestCmd.exe on it, I find the same minumum input frequency accepted is still `"Freqs": [0.062000001]`, so yeah not exactly matching behavior, but I still think that the SEH exception implementation (or fixing RMS Express) could be the best solutions. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #27 from Eric <eric.wheez(a)gmail.com> --- I believe I've solved the mystery of where the crash is coming from and have an idea for maybe how to fix it for future cases like this, though I'm not entirely certain since I'm not very savvy with programming yet. Comparing RMS Channels.dat to this Gateway Channels database: https://www.winlink.org/content/gateway_channels (select ARDOP), I found that the 9W2RUT station's input frequency is probably a typo in RMS Channels.dat (since the Gateway Channels database link says that 9W2RUT is supposed to be on 7,093.000 KHz) Station | Freq Database | Our Frequency | RMS Channels.dat -> dvoa.dll (as sent from RMS) | (KHz) | (MHz) | (Hz) -> (MHz) ------------------------------------------------------------------------------------ DA5UDI | 7,051.400 KHz | 7.051400 MHz | 7051400 -> "Freqs": [ 7.05] (works) test | n/a | 0.054999 MHz | 54999 -> "Freqs": [ 0.05] (Delphi CRASH!) 9W2RUT | 7,093.000 KHz | 0.007093 MHz | 7093 (TYPO!) -> "Freqs": [ 0.01] (Delphi CRASH!) I got in contact with the author of D-VOACAP (dvoa.dll) to see if these crashes on low-value frequency inputs were normal. He let me know that dvoa.dll is not supposed to handle frequencies below 2 MHz: "The VOACAP algorithm works in the frequency range from 2 MHz to 30 MHz. It has poor accuracy below 4 MHz and falls apart completely below 2 MHz. Please see this paper for the details." https://github.com/VE3NEA/DVOACAP/issues/3 I also learned but looking through the dvoa.dll code that these Delphi exceptions are normal behavior - the author has dvoa.dll print an error message if frequencies are too low. https://github.com/VE3NEA/DVOACAP/blob/6032495873534dec33b124b722c9a67071af9... I'm guessing here but I believe that this programmer-generated error then might be seen by wine-mono as 0x0eedfade and then crashes wine-mono. Knowing all this, I think I'll reach out to the RMS Express devs to have them fix the typo in the 9W2RUT station in RMS Channels.dat, but I'll also suggest to them some exception handling in RMS Express to warn users about calculating frequencies below 2 MHz. That should fix the RMS Express side. I think it's useful to know that wine-mono crashes when Delphi/Pascal programs throw programmer-generated error messages though. Maybe telling wine-mono to ignore 0x0eedfade Delphi exceptions could prevent future wine-mono crashes in these cases? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #28 from Esme Povirk <madewokherd(a)gmail.com> --- I just found this, and it's a lot of information to sort through but I did notice: Exception Thrown, Exception type : System.Runtime.InteropServices.SEHException, It's a known bug that we do not translate Windows SEH exceptions into SEHException objects that can be handled by the program. So if that's "supposed" to happen (happens on Windows), and the SEHException is handled by managed code, that would explain the crash. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #29 from Eric <eric.wheez(a)gmail.com> --- Thank you so much for reading all of this. You've already done so much work, I really appreciate it. Apologies for the deluge of info - I kept thinking I had gotten as far as I could get on my own but then kept thinking up different angles to look at the crash from. I think my first and last posts here are a decent summary of the info. I do believe that the SEH exception in .NET / RMS Express on Windows is normal behavior caused by whenever dvoa.dll is given a small-value frequency to calculate and tries to tell users that it can't calculate anything. Thanks for the insight into this too - that makes more sense. The good news is the crash is able to be worked around now that we know where it's coming from. The typo in the RMS Express database was also fixed (though another database typo in the future is always possible). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 Eric <eric.wheez(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor CC| |eric.wheez(a)gmail.com URL| |https://github.com/WheezyE/ | |Winelink/issues/16 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #30 from Bruni <earns.61(a)gmail.com> --- (In reply to Eric from comment #29)
I think my first and last posts here are a decent summary of the info.
Many devs have commenting periods with intermediate results too. See https://bugs.winehq.org/show_bug.cgi?id=32316 https://bugs.winehq.org/show_bug.cgi?id=50849 Your comments are not duplicates, related to the subject, not offensive, and caused by a deep-buried unmanaged Delphi exception. They do not contradict reasonable notions as well. Despite their verbosity, they do not look like explicit noise. (but comment #23, seemingly :)) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 vangli(a)online.no <vangli(a)online.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vangli(a)online.no --- Comment #31 from vangli(a)online.no <vangli(a)online.no> --- Hi. Just an update on this particularly problem. I also meet this problem using Wine 8.20 (Develop) and Winlink Express 1.7.11.0. Explicit, the notions about dvoa.dll caught my attention. I downloaded the source code, written in Pascal, and cross compiled it to 32-bit win32 DLL with freepascal 3.2.2. I then replaced the dvoa.dll installed by Winlink Express with this new one. Then updating of RMS channels propagation indices works flawlessly. I am now running Wine in 32 bit mode on Ubuntu 22.04 64-bit. I have not yet tested it with standard Wine installation (64-bit), but all the other 32-bit parts worked there too, before I switched to 32-bit mode in Wine. I just followed the guidance given by the original author Alex VE3NEA on how to compile. I am not allowed to upload the rebuilded dll, else I would have done that. https://github.com/VE3NEA/DVOACAP/blob/master/Readme.txt 73 de LA9RT, Bent -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 Eric <eric.wheez(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #32 from Eric <eric.wheez(a)gmail.com> --- Thank you Bent for the cross-compiled DLL of Alex's Delphi code! (I haven't actually tested small frequencies yet to see if the crash is gone, but I'll re-open if needed). This cross-compiled DLL was later rolled-into the official Winlink Express install. I'll close this issue for now. ----------------- Bent also documented how to cross-compiling the DLL on this groups.io: https://groups.io/g/VARA-MODEM/files/Wine/Setup%20Winlink%20Express%20and%20... Compiling the DLL This part is more for reference and if someone else also want to do it for themselves. You may download the source code from https://github.com/VE3NEA/DVOACAP. It is written in Pascal by VE3NEA – Alex. I use Lazarus and FreePascal a lot (https://www.lazarus-ide.org/ and https://www.freepascal.org/), so this was a positive discovery. Since I am running Linux, the first thing is to build a cross-compiler for FreePascal targeting 32-bit Windows. I have FreePascal version 3.2.2 installed, and this I used as given in the following description. ``` # Navigate to the fpc source folder. cd /usr/share/fpcsrc/3.2.2 # Compile the cross-compiler. sudo make clean all OS_TARGET=win32 CPU_TARGET=i386 # Install the cross-compiler. sudo make crossinstall OS_TARGET=win32 CPU_TARGET=i386 INSTALL_PREFIX=/usr # Using Lazarus, link the cross-compiler and place the link where Lazarus # can see it. sudo ln -sf /usr/lib/fpc/3.2.2/ppcross386 /usr/bin/ppcross386 ``` As you can see, the cross-compiler is named “ppcross386”. Presuming you have downloaded the source code, you move to that directory. In my installation that is: ``` username(a)machinename:~$ cd ~/Pascal/Dvoa/DvoaDll # Cross-compile the DLL username(a)machinename:~/Pascal/Dvoa/DVoaDll$ ppcross386 -MDELPHI -B -Twin32 - fPIC dvoa.dpr ``` These options tells FreePascal to use Delphi mode, Windows 32 bit and position independent code. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #33 from Eric <eric.wheez(a)gmail.com> --- I was able to run some tests and confirm that this is indeed fixed now with the newly cross-compiled DLL. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 --- Comment #34 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52131 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #35 from Austin English <austinenglish(a)gmail.com> --- Actually closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla