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 - Lars

Pages: 1 ... 31 32 [33] 34 35 ... 86
481
Programming / Re: JSon to Rexx (stem)
« on: May 22, 2021, 11:17:06 am »
If I catch it in time, I can ctrl-C to stop it. Otherwise only the power switch.

There are C language JSON interpreters, but it was so nice to have the REXX one.

The website at https://jsonformatter.curiousconcept.com/ says the file is valid JSON, and it shows that the file is really not that complex. There are just 11 items, one of which is an array.
I take it, the recursion never stops and eventually blows the stack. And then there seems to be a bug in the REXX interpreter to hang the whole system.

482
Programming / Re: JSon to Rexx (stem)
« on: May 22, 2021, 11:14:53 am »
Maybe the easiest thing would be to wrap the C code with the REXX Interface. That will give you a good performance and still allow you to use it from REXX. But of course, you'll either need the C Source or a DLL to link to (with a published interface).

483
Programming / Re: JSon to Rexx (stem)
« on: May 21, 2021, 12:39:11 pm »
What does "it never completes" actually mean? Does it even prevent you from doing a Ctrl-C?
The script contains a recursive function. In case of programming error, it could loop forever and also use up all of the stack. But of course, you should still be able to do a Ctrl-C.

484
Hi Lars,

Quote
But the patches only work for very old versions of USBMSD.ADD and with some likelyness, this error has been fixed with newer versions of USBMSD.ADD.

This was back in the day when Olympus had propriety USB drivers, they fixed the problem by allowing access to cameras as if they were USB drivers/keys.
That update is only required if someone is using very early model Olympus cameras from around 20 years ago.

In saying that, thanks for the info, I have moved that file to the usb/old directory on 'my' os2site.com and updated the descriptions. Hopefully that will be pushed out to the public www.os2site.com when I have replication sorted.

Was that the problem with the incorrect signature of USBU instead of USBS in the status block?
I have a USB filter driver (it's rather the driver from EXIGEN to show the filter concept) that fixes that on the fly. Without any need to change USBMSD.ADD. That filter driver is in my USB repo. I never released it but I could.

485
I agree with what Ivan says: outdated drivers should go into an "archived" subpart. If a driver is updated, there usually are very good reasons why that happens. An old driver archive is only valuable if there is either additional info or source code in it (which almost never happens).
Right now, I can see in Hobbes an old patch for USBMSD.ADD from Yuri Dario to make USBMSD.ADD work with an olympus digital camera (USBMSD_patch_2002-08-09.zip). But the patches only work for very old versions of USBMSD.ADD and with some likelyness, this error has been fixed with newer versions of USBMSD.ADD.
What's more, this patch set has been uploaded to OS2SITE with a different name (usbmsd13b.zip), just adding to the confusion.
A new user would likely try to desperately downgrade his version of USBMSD.ADD so the patch can be applied, and along with it, break everything else.

It's a perfect way to drive away new users.

486
I am not sure if OS/2 2.1 supports GRADD video drivers.
I remember that OS/2 2.0 initially only supported 16-bit video drivers ! Boy, that is such a long time ago..

487
I would hope that the system keyword will pull in correct startup code and libraries. It should never be necessary to explicitly link the correct startup code (that's just too involved and error prone for the average developer).

488
Hardware / Re: OS/2 on Virtualbox with 8 COM ports
« on: May 10, 2021, 11:34:13 am »
If you can supply HW that defines I/O mapped registers (but NOT memory mapped) as the usual register set (Line control reg, mode control reg. etc.) and this register block is contiguous as usual for each supported HW I/F, then the default COM.SYS driver will do. COM.SYS just assumes the registers to exist that existed 20 years ago.
COM.SYS will read the BAR value(s) directly from PCI config space. The rest is done with a configuration file ("stepsize" of repeated register block for each HW I/F, for example).

489
Anyone know how to use wlink to create an executable from the command line?

Using:
wlink option quiet name helloworld.exe file helloworld.obj library libc_dll.lib

gives:
Code: [Select]
Error! E2028: ___main is an undefined reference
Error! E2028: _printf is an undefined reference
Warning! W1014: stack segment not found
Warning! W1023: no starting address found, using 0001:00000000
file helloworld.obj(helloworld.obj): undefined symbol ___main
file helloworld.obj(helloworld.obj): undefined symbol _printf

Cheers,

Paul

Looks like you are not linking to the correct library/libraries. I suspect that libc_dll.lib is for creating a DLL rather than an exectuable (which then defines "dllmain" instead of "main" etc.). I think you should try the "system" keyword on the linker commandline. It should allow to easily specify what exactly you are intending to build and will hopefully then pull in the correct libraries.
See the linker help.

490
Does EMXOMF only convert from AOUT to OMF but not from ELF to OMF ? I thought that if you called gcc with the -Zomf switch that then, OMF objects would he produced ?

491
As you can see, changes to files are logged and can be queried. But you will have to specify a set of paths to look for. I don't know if directories are supported recursively.
Yes, interesting. But the cited notify actions seem to handle only changes of files or dirs in a folder. I don't see anything that can be used to track opened files. Am I wrong?

May be you can have a look on :
Lsof (List Open Files)
https://ecsoft2.org/lsof-list-open-files

I just did a try, and could find opened pdf, odt, txt ...  (pmview open files aren't listed but it has an integrated recall option)
May be use a very simple daemon, extract entries according a list of file type and add/update WPS object under a "Recently opened file" folder with the correct full path name, file extension having the correct associated extension, it should open when click on it. 

RD

This tool does something completely different from what we are talking about. LSOF lists all file (handles) that are currently open by all currently executing processes. This even includes device handles. Not what we want.

492
Actually, there exists an API on file system level that happens to be only documented in the DDK, here it is (discussion found in some forum):

Code: [Select]
[later] After perusing \ddk\h (A great place find
"undocumented" os/2 APIs), it appears that you may the
correct -- the DosFindNotify...() apis no long exist as
32bit apis (but you can still import the 16bit ones if if
like).

They appear to have been replaced by something better
(which probably uses the FindNotify IFS services
underneath). You'll have to figure these out on your own
(please report back here);but they don't look too hard:

#pragma pack(1)

typedef struct _CNPATH { /* CHANGENOTIFYPATH */
ULONG oNextEntryOffset;
ULONG wFlags;
USHORT cbName;
CHAR szName[1];
} CNPATH;
typedef CNPATH *PCNPATH;

typedef struct _CNINFO { /* CHANGENOTIFYINFO */
ULONG oNextEntryOffset;
CHAR bAction;
USHORT cbName;
CHAR szName[1];
} CNINFO;
typedef CNINFO *PCNINFO;

#pragma pack()

// Equates for ChangeNotifyInfo baction field

#define RCNF_FILE_ADDED 0x0001
#define RCNF_FILE_DELETED 0x0002
#define RCNF_DIR_ADDED 0x0003
#define RCNF_DIR_DELETED 0x0004
#define RCNF_MOVED_IN 0x0005
#define RCNF_MOVED_OUT 0x0006
#define RCNF_CHANGED 0x0007
#define RCNF_OLDNAME 0x0008
#define RCNF_NEWNAME 0x0009
#define RCNF_DEVICE_ATTACHED 0x000A
#define RCNF_DEVICE_DETACHED 0x000B

APIRET APIENTRY DosOpenChangeNotify(PCNPATH PathBuf,
ULONG LogSize,
PHDIR hdir,
ULONG ulReserved);

APIRET APIENTRY DosResetChangeNotify(PCNINFO LogBuf,
ULONG BufferSize,
PULONG LogCount,
HDIR hdir);

APIRET APIENTRY DosCloseChangeNotify(HDIR hdir);

As you can see, changes to files are logged and can be queried. But you will have to specify a set of paths to look for. I don't know if directories are supported recursively.

493
Quote
"most recent files" is a global function. I don't see any point in making that "per application".

Agree.

Quote
Screwing around on file system driver level is counterproductive and completely superfluous.
IMHO dangerous. And maybe a performance disaster. I wouldn't risk to try it out by myself.

Quote
There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level.
Sounds like a very elegant way. But does this also work when you f.i. open a file from cmd line in an editor which writes this file afterwards. And do you get notifications when you f.i. open a pdf by double clicking in the email client which fires up qpdfview and when do 'Save as' in qpdfview?

No, it would only work for files opened via the WPS, but see last paragraph. But that's exactly the question: what are the REAL expectations ? If you use an app to open files and that app already has support for "most recently used docs" then there is no need to offer that via the WPS.

The WPS knows nothing about applications. But it can detect that files were being modified on file system level (I don't know if this is limited to file content or also for changing EAs).

494
Applications / Re: Most Recently Opened Documents - Discussion
« on: May 04, 2021, 09:12:10 am »
"most recent files" is a global function.
Do apps use that WPS function? (I assume that's also the one been used for reopening file objects on opening work area folders, which doesn't work for all apps.)
My understanding of that function is a collection of any files that were open on the desktop.These should be recallable and presented in a container where they can be double clicked and the default WPS action invoked on them.
For many apps that need it, an application specific list already exist. I see no need to duplicate that.
The user would invoke that function, not an application.

495
Applications / Re: Most Recently Opened Documents - Discussion
« on: May 03, 2021, 08:24:05 pm »
"most recent files" is a global function. I don't see any point in making that "per application". But maybe I am lacking some phantasy.
Screwing around on file system driver level is counterproductive and completely superfluous. There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level. Taking all that is sufficient to come up with a "most recent files" WPS class.  And if you go for only the last 20 files, then writing this info to OS2.INI is also acceptable in my point of view.
I love reusing code, I hate writing own code.
Writing your own code means testing which typically takes far more time then writing it.

Pages: 1 ... 31 32 [33] 34 35 ... 86