Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Steven Levine

Pages: [1] 2 3 ... 7
1
Wim,

That's it, although the content is not quite what I expected.  For some reason, the object on the system I was searching on had the title "Trouble", which is now fixed.

I should have thought to search the .infs for the title, but I didn't.

Thanks.

2
While analyzing a WSeB issue, I ran into a reference in the Network Administrator Tasks guide that stated

  "For problem determination tasks, refer to the Serviceability and Troubleshooting Guide."

None of my WSeB install media seem to have a copy of a document by this name.  Nor do web searches or the AIs find anything relevant for WSeB.  Has anyone ever seen a copy of this document?

3
Applications / Re: General Software Testing
« on: October 09, 2025, 11:00:12 pm »
Martin,

Looks like stack overflow.  Unfortunately, it's the thread two stack, so you cannot just modify the LX header and build the stack size.  Somone would need to rebuild the app and modify the beginthread call to allocate a larger stack.

4
Programming / Re: EDM/2 - The API Project - Undocumented
« on: October 07, 2025, 02:00:38 am »
Martin,

It cannot hurt to document what we know and to document any educated guesses we might have.

This has a couple of benefits IMO.  One, it helps avoid, at some future time, redoing the analysis that's already been done.  Two, it might get someone sufficiently curious to investigate further.

There's really no tricks required to get additional information.  Quality time spent with a debugger or a disassembler will eventually provide all the answers you might like to have.

Whether or not this will be time well spent is for the person doing the work to decide.

The GPI Guide and Reference provides a lot of hints and to what GpiAbortPath does.  Take a look at the sample code for GpiBeginPath. Given what we can see, I would expect GpiAbortPath to take a single HPS argument, as does GpiEndPath.  I would also expect GpiAbortPath to release the resources allocated by GpiBeginPath and the other path building functions.  See the GpiBeginPath Remarks panel for some discussion on how this all fits together.

The ddk sources have real world examples of these path APIs in the testtool sources.

5
Communication / Re: Zoc and Transfers
« on: September 10, 2025, 06:24:50 am »
Hi all,

This is some sort of buffer overflow which possibly corrupted the stack.

09-08-2025  15:43:36  SYS3175  PID 0059  TID 0001  Slot 007e
C:\ZOC\ZOC.EXE
c0000005
1c27b216
P1=00000001  P2=415c3a43  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000000  EBX=00000001  ECX=ffffffff  EDX=415c3a43
ESI=0004f404  EDI=415c3a43
DS=0053  DSACC=d0f3  DSLIM=5fffffff
ES=0053  ESACC=d0f3  ESLIM=5fffffff
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1c27b216  CSACC=d0df  CSLIM=5fffffff
SS:ESP=0053:0004d470  SSACC=d0f3  SSLIM=5fffffff
EBP=0004d484  FLG=00010286

MEGADODO.DLL 0001:0000b216

Without looking at the megadodo.dll code, what I see in the popuplog is a typical pattern of a strlen call gone bad.  ECX is the scan length and EAX is the nul character and EDI points to the string.

EDI looks like text when it should be a pointer.  A bit of REXX displays

  [d:\tmp]rexxtry say reverse(x2c(415c3a43))
  C:\A

provides more evidence in addition to looking like that start of a path string.

Since the exception occurs after you select a file, it would appear that there's something about the selected directory or file name that is triggering the issue.  ZOC is a 32-bit app and should fully support long file names, but
one never knows for sure.  I would try selecting a file with a short name from a directory with a short name, as a trest.

Another possibility is the File Open Controller.  If you have it enabled, I recommend disabling it or adding ZOC to the exceptions list, as a test.

FWIW, ZOC appears to be built with VAC 3.08.  There's even some IBM HLL debug data in a couple of the modules.

Oddly the ORDER.EXE I have looks to be a Windows app which might be an error in the distro.

6
Communication / Re: Zoc and Transfers
« on: September 09, 2025, 06:53:41 am »
At what point during the upload request process did ZOC terminate?

Did you check for popuplog entries?

There's lots of serial terminal program options.  See

  https://hobbesarchive.com/?path=/pub/os2/util/remote

FWIW, ZOC has always been my goto and pretty much trouble free, although it's been a while since I used it for file transfers over serial.

7
Hardware / Re: Smart Hard Drive Monitoring on AOS 5.1.1
« on: August 05, 2025, 09:18:06 pm »
Dan,

I recommend you hold off until the netlabs server is fully back online.  My testing indicates that this is not yet happened.  URLs that were available before the server went down are not yet visible including http://rpm.netlabs.org/release/ which is the top level directory for the released rpms.  The same is true for http://rpm.netlabs.org/experimental/.

It's possible Adrian needed to take the server offline to finish up the recovery.

8
Article Discussions / Re: Games with older SDL and FSLIB
« on: July 18, 2025, 07:21:23 pm »
Dave,

Do you mean token?  Github switched over to token based passwords several years ago.

https://github.com/settings/tokens

9
Programming / Re: Networking: socket() returns positive `non-socket`
« on: July 07, 2025, 10:31:59 pm »
Are your C functions statically linked into agena.exe?  It's not clear from your example.

If your C functions are linked into agena.exe or are in a DLL linked to agena, baring defects, the code should work as you expect.

While sock only has a value during the function call, you have exported the value to L and I assume the exported value is global and persistent.

I recommend adding a bit of debugging code to printf the value of sock in both functions.

Just returning from a function call is not going to close the socket.  The socket will stay open until explicitly closed by your code or when the executable terminates.

You can watch the state of the socket with netstat -s.

To understand how kLIBC maps sockets to file handles see:

  src\emx\src\libsocket\socket.c:41
  int socket(int af, int type, int protocol)

at

  https://github.com/bitwiseworks/libc

10
Programming / Re: Networking: socket() returns positive `non-socket`
« on: July 07, 2025, 02:42:50 am »
As Dave mentioned, we need know a bit more about your development setup and build options.

Since you are building with gcc, I'm going to assume for now that you are building with kLIBC and you are using the most recent versions of libn0.dll and libcx0.dll from the netlabs repos.

You should be using the OS/2 toolkit headers provided by the libc-devel package.  They work better with gcc and kLIBC than the IBM supplied headers.

FWIW, addsockettolist and removesocketfromlist are documented and they are used by kLIBC.  kLIBC needs them to implement fork().

Another FWIW, I have seen the ENOTSOCK failure mode when running git against large repositories on a busy system, but perhaps not for the same reason you are.  In my case the failure is intermittent and retrying the git operation when the system is less busy typically avoids the failure.

Note that OS/2 has separate namepaces for sockets and file handles, unlike Linux.  kLIBC emulates the Linux way to make porting apps simpler.  This requires using kLIBC for all file and socket operations.

11
Internet / Re: Dooble releases-Qt6
« on: June 07, 2025, 10:16:28 pm »
SWAPPATH has nothing to do with available address space.

12
Programming / Re: Qt6 Development
« on: June 07, 2025, 10:14:45 pm »
Have you discussed the with BitWiseWorks?

13
Programming / Re: Qt6 Development
« on: June 07, 2025, 06:19:46 pm »
Martin,

What is your definition of mainstream?  An rpm in some pubic repository or something else?

14
Internet / Re: Dooble releases-Qt6
« on: June 07, 2025, 09:35:53 am »
Neil,

I recommend you verify your VIRTUALADDRESSLIMIT setting.  Your mem /v output:

 Available virtual memory:   1,424 MB

looks to me like I would expect it to appear for VAL 1536.

15
Programming / Re: EDM/2 - The API Project - Undocumented
« on: May 27, 2025, 08:42:25 pm »
My choice would be DevHlp_RAS for assembler usage and for DevHelp_RAS for C usage because these are what you will find in pdd.ref and the DDK sources.

FWIW, the references you found to DevHlp_AddTraceEvent and DevHlp_SysTrace in the SMP Addendum are not Device Help definitions.

DevHlp_AddTraceEvent is the description the writer chose for Hook ID 61/34 which represents a location in the kernel code.  I've yet to find any actual Device Helper related code that actually uses this symbol.

DevHlp_SysTrace is part of a comment in the assembly language example for dh_PerfSysTrace.  Again, I've yet to find any actual Device Helper related code that actually uses this symbol.

It probably cannot hunt to mention these alternative references to DevHlp_RAS and DevHelp_RAS, although I'm not sure how I would describe why they exist.

Pages: [1] 2 3 ... 7