Problem with DEBUGGER with external application

Master (221)

08-02-2023, 16:13

I'm trying to control the OpenMSX debugger from an external app for my personal use. I have read the documentation, but I am seeing a "problem".
I can connect via socket to openMSX, but I can't extract data. This also happens to me from the command console. I show a photo where everything is explained. In windows when sending a command it gives me a syntax error, while in linux that same command gets a satisfactory result. Is there something I'm missing? Therefore, my external application doesn't work either, but since it doesn't work from the Windows 10 command console, I think it could be a problem between OpenMSX and Windows 10. Is there any way to check this? Thank you.

[img][/img]

Por wouter_

Hero (522)

08-02-2023, 17:31

Hi,

The image has too low resolution, it's very hard to read. In particular I can' read the error message at all.
What I think I can still see in the image is that you're using "-control pipe" (in windows) vs "-control stdio" (in linux). What if you also use "-control stdio" in windows? Just as a test to see what happens.

I might be able to help you better with a readable image. Or better: just provide the error message in text (copy/paste).

Por JACS

Master (221)

08-02-2023, 18:40

https://ibb.co/W5ghKVz

using "-control pipe" (in windows) vs "-control stdio" :

Thank you for answering so quickly.
I hope you can download the image or I will upload it again.
Regarding one of your questions:
Yes, I have tried pipe and stdio, but the result is the same.
I have to say that the official frontend debugger does work well, but I can't do it in my application.
In case it is not appreciated, the error that it gives me is "the syntax of the command is not correct"
If any user has windows to test only this part...

[img][/img]

Do click for zoom.

Por wouter_

Hero (522)

08-02-2023, 19:10

Sorry, same problem. The image https://i.ibb.co/pwJ7XhK/error-Windows.png only has a resolution of 639x335, that makes many of the text unreadable. But in any case, I don't think a screenshot is very helpful.

Can you give more details about what exactly you send over the connection with openMSX? Do all commands fail? Or only specific commands? (Which one?) Can you share the source code of your program?

Note that openMSX expects UTF8 encoded input.

Por santiontanon

Paragon (1805)

08-02-2023, 19:48

Clicking on the image in the first post, I do see it high res (just wait a few seconds for it to load, at first it's just displaying a low-res preview)

Por JACS

Master (221)

08-02-2023, 20:52

As SantiOntanon says, clicking on the 1st image zooms. However, if there are problems, forgive the inconvenience and let me know again.

https://openmsx.org/manual/openmsx-control.html

here it says that for windows you should start openmsx like this: openmsx -control pipe
This works, but when doing the following instruction: set renderer SDL the terminal returns an error: "the syntax of the command is not correct", but this same thing done in linux, does not give any error and openMSX returns a message "reply=OK"(in linux ok, on windows KO)

Por Parn

Paladin (837)

08-02-2023, 22:12

Windows user here, I tried to reproduce @JACS' problem.

I just type openmsx -control pipe (or stdio, both give out the same results). After a small pause, the command prompt just shows my current path again, followed by <openmsx-output>, and puts my cursor at the beginning of the next line. It looks like it may accept OpenMSX control commands, but it's still listening to prompt commands. At this point, if I type anything that OpenMSX would accept, it just says "the syntax of the command is not correct", but in my localised Windows language. If I type any valid prompt command, like dir, it just prints out its expected output.

It isn't clear what's the exact mechanism to send control commands to OpenMSX at this point. It just looks like it's doing nothing.

EDIT: This is my sample output.

C:\Program Files\openMSX>openmsx -control stdio

C:\Program Files\openMSX><openmsx-output>
dir
 O volume na unidade C não tem nome.
 O Número de Série do Volume é 98FF-0D6A

 Pasta de C:\Program Files\openMSX

27/01/2023  08:30    <DIR>          .
02/02/2023  03:37    <DIR>          ..
26/08/2022  08:45    <DIR>          Catapult
26/08/2022  08:45    <DIR>          codec
03/03/2022  21:32    <DIR>          debugger
03/08/2022  22:04    <DIR>          debugger-new
27/01/2023  08:30    <DIR>          debugger-newest
03/03/2022  21:40    <DIR>          debugger-pvmm
26/08/2022  08:45    <DIR>          doc
12/06/2022  09:34         9.290.752 openmsx.exe
26/08/2022  08:45    <DIR>          share
               1 arquivo(s)      9.290.752 bytes
              10 pasta(s)   433.176.240.128 bytes disponíveis

C:\Program Files\openMSX>

Por JACS

Master (221)

08-02-2023, 22:34

Exactly. This is the problem. But in Linux Works well.
Can a programer of OpenMsx debug This issue in Windows?

Por turbor

Hero (520)

08-02-2023, 23:51

JACS wrote:

Can a programer of OpenMsx debug This issue in Windows?

I think that is kind of the problem.Currently we don't have an openMSX developper who is a Windows programmer. Most of us simply don't run Windows. If a volunteer would be so kind to step up and help us out on this, it would be highly appreciated.

Por Manuel

Ascended (19462)

09-02-2023, 00:05

The errors you get are from the command prompt, not from openMSX. So, looks like your command prompt/terminal isn't connected to stdin of openMSX. Still, openMSX Catapult uses the same mechanism (with stdio). If that works, openMSX is OK. Perhaps the issue is that on Windows openMSX is compiled as a "Windows application" (so not command line), and that may somehow interfere?

Por JACS

Master (221)

09-02-2023, 10:16

I just checked that in OpenMSX versions 0.13 and 0.15 it is possible to use the command line OpenMSX -control stdio . In this case, it does receive orders and responds correctly. Versions 0.17 and 0.18 some change made by developers that this feature is disabled. If you could look...