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 - Dariusz Piatkowski

Pages: [1] 2 3 ... 94
1
Applications / Re: PMMail fails sending messages
« on: January 20, 2025, 08:33:59 pm »
I am desperatly trying to make PMMail sending messages without success.
I am a registered user and I am running PMMail 3.11.30.1767.
Receiving messages works pretty good. But sending doesn't.
...
Any hints what to try to make PMMail send messages succesfully?

What does PMMail log show?

You can find it here: Toolbar => PMMail => View Program Log File

As an idea: could you use POP to handle your Outbound email tasks? I realize that POP is not meant for that, but PMMail 'Send' tab certainly shows POP as a viable choice here (at least on my 3.25 release).

Here is a decent review of all the protocol options => https://world.siteground.com/tutorials/email/protocols-pop3-smtp-imap/

2
Programming / Re: Qt6 Application Testing
« on: January 20, 2025, 05:03:20 pm »
Hello Remy,

Ok, read it.
I don't understand why when adding this switch, Dooble is more stable while it should have no effect but it has here !
(adding this switch, I'm able to use Dooble without setting priorities. Without it, I need to add priorities settings)
 
May it be possible this constant isn't well taken into some parts of the codes ?

Could it be that this SET statement impacts other apps on your system which in turn have an impact on the QT stuff?

I have a few apps here that would fit the bill:
1) FF - where I no longer have this set, while in earlier versions I did
2) PUMONITOR - by default I'm using the hires timer to gether runtime statistics
3) DISKIO - the version I am currently working on is using this approach

Now of course if you are running/testing the QT apps w/o anything else on your OS/2 box currently running, that would at least limit that spillover effect that other apps might have.

3
hi mauro,

ah, ok.  more exactly:
I'm in SM window browser, I browse the web, then if I want to start a new mail message I can do it (compose message window selected from FILE menu opens, I write the message and send it). But I cannot touch the item Mail & Messages from WINDOW menu, the one which opens the email folders pane, at that point OS2 traps.

OK, I understand now...so this is all within the SM application, which I do not have installed here.

When you mentioned that you installed FF I thought I could try to help/test with my FF & TB combo, unfortunately I do not think this is possible. Maybe I misunderstood one of the posts though..sorry about the noise.

4
mauro,

...Dariusz, not understood what you're asking me to do: having both FF and TB installed and then what action...?

OK, in your original post you stated:

...recently discovered that now the email client of Seamonkey -assuming same as Thunderbird-, cause a system trap when calling the "email client" window from Seamonkey (no problem if I start a new message compose)...

I interpret that to mean:

1) you are in web page (browsing) where there is an email link
2) you click on that link and expect that the email client window would pop up, thus allowing you to create an email
3) instead of this outcome you experience a trap/failure

Is that correct?

Subsequently in your post I was responding to you stated:

Quote
...I have installed Thunderbird 45.8 pentium4 to see what happens...

...and I was commenting on the fact that I have FF & TB here, which have been pretty solid for me, so I could certainly try to reproduce your scenario, and if I fail to, we could try to chase the DLLs down given that I am on CP2 release as opposed to AOS install.

5
Hello mauro,

...Just to point, I have installed Thunderbird 45.8 pentium4 to see what happens, it behaves exactly the same: it let mi begin to configure a profile plus the account, then at the moment to display the folders pane, the system goes away (trap).
Also in Seamonkey browser, it perfectly works till the request to go in the email folders pane.
No problem, I will survive without.

Can you provide a step-by-step instructions to replicate this?

Here is why I ask:

1) FF & TB installs here: they coexist very peacefully, and normally after a good 5 days of runtime I usually hard-kill FF because it grows to over 1G RAM consumption...re-starts brings it back and no issues

2) This last post of yours seems to indicate this issue can be replicated in my configuration as well (FF & TB), so I'd like to try this but w/o making any assumptions, thus the ask for 'step-by-step' instructions

I do have a 4.52 SMP install here, so the UNI vs SMP thing is certainly going to introduce a variable.

For what it's worth, here are the releases I'm running:

1) FF - 45.9.0
Code: [Select]
Compiler Version Compiler flags

gcc.exe 9.2.0 -Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -Zomf -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -fno-math-errno -pthread

c++ 9.2.0 -idirafter K:/usr/include/os2tk45 -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -Zomf -fno-exceptions -fno-strict-aliasing -Zomf -flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNDEBUG -DTRIMMED -g -march=pentium4 -mtune=generic -O2 -flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess -msse2 -fomit-frame-pointer

Configure arguments
--enable-application=browser '--enable-optimize=-march=pentium4 -mtune=generic -O2 -flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess -msse2' --disable-debug --enable-debug-symbols --disable-tests --enable-os2-high-mem --without-x --enable-official-branding --enable-system-cairo --enable-system-pixman --with-intl-api --with-system-icu --with-system-zlib --with-system-libvpx --prefix=/usr --disable-webrtc --disable-telemetry --disable-devtools --disable-crashreporter --disable-gamepad --disable-web-speech --disable-updater --disable-startupcache


2) TB - 45.8.0
Code: [Select]
Compiler Version Compiler flags

gcc.exe 9.2.0 -Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -Zomf -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -fno-math-errno -pthread

c++ 9.2.0 -idirafter K:/usr/include/os2tk45 -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -Zomf -fno-exceptions -fno-strict-aliasing -Zomf -flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNDEBUG -DTRIMMED -g -march=pentium4 -mtune=generic -O2 -flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess -msse2 -fomit-frame-pointer

Configure arguments

--enable-application=mail --prefix=/usr --libdir=/usr/lib --with-system-zlib --with-system-bz2 --enable-system-hunspell --disable-tests '--enable-optimize=-march=pentium4 -mtune=generic -O2 -flifetime-dse=1 -fno-delete-null-pointer-checks -Wclass-memaccess -msse2' --disable-mochitest --disable-installer --disable-updater --disable-debug --enable-debug-symbols --enable-system-cairo --enable-os2-high-mem --disable-crashreporter --enable-calendar --with-intl-api --with-system-icu --with-system-libvpx --with-system-png --disable-system-sqlite --with-system-jpeg --enable-release --enable-official-branding --prefix=/usr --disable-telemetry --disable-devtools --disable-crashreporter --disable-gamepad --disable-updater --disable-webrtc --enable-crypto --with-external-source-dir=Y:/work/cc45-git

6
Applications / Re: OO v3.18
« on: January 18, 2025, 02:19:32 am »
Hi Martin,

I have been using A OO 4.1.20 for OS/2 since 17-12-2015 without any problems...

Are you sure that's 4.1.20?

I ask b/c the 4.1.2 README that I have here shows the following: "...Apache OpenOffice 4.1.2...".

7
Applications / Re: Wiping a hard disk back to 'as bought' condition
« on: January 14, 2025, 12:06:02 am »
Most storage (if not all?) have that whole 'Secure Erase/Wipe' function...the intention is to do precisely what you want, and more...as in literally wipe out complete HD. Often times that can be accessed through BIOS, although the other stuff probably doesn't have that.

You can typically d/l the HDD manufacturer specific utility however, so that might be worth considering?

There are open source options as well, see http://www.dban.org/

Otherwise, to properly set up for a fresh install what Dave suggests should be plenty powerful!!!

8
Programming / Re: DISKIO - storage device detection logic
« on: January 04, 2025, 11:54:28 pm »
Hey Andi!

Not sure what you're really want to know but DataSeeker uses DosQueryFSAttach() to distinguish between different drive types. I think I copied this from 4os2 code back then but not sure anymore. Anyway http://trac.netlabs.org/dataseeker/browser/trunk/DriveInfo.c contains the code which finds out if the drive is a disk, floppy, network, CD/DVD, or .... Also if removable or not...

Aha...good stuff for sure!

This has helped me a lot in understanding how to correctly call the other DosDevIOCtl category functions and I was in fact able complete the logic for the device mapping function. Alas (see my previous thread update) that's still not enough to tell me whether a simple device # has media mounted on it and could in fact be benchmarked.

FYI - there is a very real chance here I'm missing something obvious, so don't by shy in giving me a quick smack...LOL

9
Programming / Re: DISKIO - storage device detection logic
« on: January 04, 2025, 11:43:58 pm »
Well, that few hours of work took me completely NOWHERE!!!  ::)

OK, that's good to know as I am currently looking at using the media/removable check for each device to identify whether that device should actually be tested. Basically: if the media is 'mounted', we are good, otherwise we need to skip it.
....
Therefore, what your remark tells me is that I should be fine to use that IOCTL_DISK (08h) & DSK_BLOCKREMOVABLE (20h) combo to test for presence of actual media (where a partition object is present) as opposed to just the presence of a storage device that may not in fact have any media currently loaded (thus the problem we are seeing with USB devices) - I think anyways...for now...

Yeah, I completed that function and learned that the DosOpen API won't deal with anything other than either a fully qualified filename, or in the case of a drive it must be a proper drive letter/number.

Soooo...my hope, as slim as it was, that the numbered DEVICE name could in fact be used by DosOpen was incorrect. Given this I lack a way to connect the devices that the INFO_COUNT_PARTITIONABLE_DISKS parameter gives me when calling DosPhysicalDisk to actual volume/partition objects means that I have no way to check whether a USB device currently has media mounted in it and therefore coudl be tested by DISKIO.

Lars did point out in another thread (circa 2021 => https://www.os2world.com/forum/index.php?topic=2792.0) that I may need to use DosPhysicalDisk, but the problem with that approach is in the fact that the returned device handle can only be used with DosDevIOCtl CATEGORY=09h functions and none of those functions return information about the status of media on the device itself, and I never did figure out what is that "...special "filename" to use [with] DosOpen..." either.

Hmmm... :-\

I tell ya it almost seems like core of DISKIO logic should be re-written to approach this from partition/volume perspective, which would give us visiblity to FS stuff (and thus media presence). That subsequently could be used to determine whether an actual DEVICE (which the partition/volume belong to) should be tested. Right now DIKSIO's logic is the inverse of that.

Maybe I just need to re-focus on handling the exception that arises when an unmounted-media USB device is being benchmarked so that this exception can be correctly handled...LOL?

10
Programming / Re: DISKIO - storage device detection logic
« on: January 04, 2025, 03:51:09 pm »
Hello Lars,

I seem to remember that IOCTL_PHYSICALDISK was for accessing all sectors of a physical disk whereas IOCTL_DISK was for accessimg a drive / a volume (or partition) of a disk.
So that has nothing to do with device type.

OK, that's good to know as I am currently looking at using the media/removable check for each device to identify whether that device should actually be tested. Basically: if the media is 'mounted', we are good, otherwise we need to skip it.

Here is the WIP logic (ignore the obvious missing declarations, etc, this is just general logic with some specific API stuff tossed in as anchors):

Code: [Select]
void device_map (int iDisks, int iCDROMs)
{
   int      iCnt;
   APIRET   rc = NO_ERROR;

   // we have a TOTAL number of HD-type and CDROM-type devices now, so let's
   // take a pass through them all and check to see if they have mounted media
   // in them, if YES, that means we can test, otherwise, we should NOT!
   for (iCnt = 0, iCnt < iDisks, iCnt+)
   {
      // what device am I processing?
      sprintf(szName, "$%d:", iDisk);

      // let's get a handle for this device
      if (DosOpen (szDrv,                                      /* device name */
                   &hfHandle,                     /* address of device handle */
                   &ulAction,              /* address of DosOpen action taken */
                   0,                               /* logical size of device */
                   FILE_NORMAL,                                 /* attributes */
                   FILE_OPEN,              /* action to take if device exists */
                   OPEN_FLAGS_DASD | OPEN_FLAGS_FAIL_ON_ERROR |
                   OPEN_ACCESS_READWRITE | OPEN_SHARE_DENYREADWRITE,  /* mode */
                   0)                           /* device extended attributes */
      {
         // call the DosDevIOCtl API here
         if (DosDevIOCtl (HANDLE (hfDevice),                    /* device handle */
                          IOCTL_DISK,               /* category of request - 08h */
                          DSK_BLOCKREMOVABLE,  /* function being requested - 20h */
                          pParms,                 /* Input/Output parameter list */
                          ulParms,        /* size of Input/Output parameter list */
                          &ulParmLengthInOut,  /* Input: size of parameters list */
                                          /* Output: size of parameters returned */
                          pData,                       /* Input/Output data area */
                          ulData,              /* size of Input/Output data area */
                          &ulDataLengthInOut); /* Input: size of input data area */
                                                /* Output: size of data returned */
         
         // now parse the result and update the global device structure record
         // WIP
      }

      // display the device status information here
      // WIP

   }

} // end of device_map

Subsequently that "global device structure" record would be used by the remainder of the DISKIO logic to check whether the particular device should, or should not be benchmarked.

Therefore, what your remark tells me is that I should be fine to use that IOCTL_DISK (08h) & DSK_BLOCKREMOVABLE (20h) combo to test for presence of actual media (where a partition object is present) as opposed to just the presence of a storage device that may not in fact have any media currently loaded (thus the problem we are seeing with USB devices) - I think anyways...for now...

11
Programming / Re: DISKIO - storage device detection logic
« on: January 03, 2025, 04:58:55 pm »
Alright, a bit of an update.

I spent considerable amount of time over the holidays trying to understand the DISKIO 'device type' detection logic. This is important because the remaining code execution pathway is largely based on what type of a device is being processed.

In short, there are three types recognized, which in turn control the definition of DosDevIOCtrl CATEGORY call.

This section declares two of them:
Code: [Select]
#define PHYSICAL     0x1000   //4096
#define CDROM        0x2000   //8192

Later on a dynamic CATEGORY assignment is made through the following macro:
Code: [Select]
CATEGORY(x)  (((x) & CDROM) ? IOCTL_CDROMDISK : ((x) & PHYSICAL) ? IOCTL_PHYSICALDISK :IOCTL_DISK)

So basically:
if device=CDROM, then CATEGORY = IOCTL_CDROMDISK
if device=PHYSICAL, then CATEGORY = IOCTL_PHYSICALDISK
else CATEGORY = IOCTL_DISK

Indeed, in my debugging I have found the following to be substantitated:

1) HD        - 4099, which means DosDevIOCtl is given CATEGORY = IOCTL_PHYSICALDISK (09h)
2) CDROM - 8195, which means DosDevIOCtl is given CATEGORY = IOCTL_CDROMDISK (80h)
3) USB      - 4099, which means DosDevIOCtl is given CATEGORY = IOCTL_PHYSICALDISK (09h)

...alas, and here is where our problems arises: both HD and USB storage devices are treated like the same category device, that being IOCTL_PHYSICALDISK.

At the moment my stipulation is that the use of "...else CATEGORY = IOCTL_DISK..." was intended to cover stuff like USB based devices...but that's just a guess, and maybe that was even meant to support throughput testing on remote storage devices? (think UNC \\server\mount_point type of stuff)

So to get this under control what I would like to do first is to correctly recognize a USB storage device as such and differentiate it from both the CDROM as well as regular HD.

So where does that device handle come from (which is then logically AND'ed in that MACRO)? Well, that comes from a call to DosOpen, or DosPhysicalDisk (in which case only the IOCTL_PHYSICALDISK (09h) can execute).

...in turn, this begs the question on my part: should either DosOpen or DosPhysicalDisk not have the ability to properly recognize a USB based storage device as being different than a regular HD, and therefore return a handle which leads me down the path of CATEGORY = IOCTL_DISK???

Seems like there is something missing in this logic and I can't quite put my finger on this.

Once I understand this I think I will be in a better postion to determine which approach is most suited to determine if a USB based storage device actually has mounted media in it, that could in fact be tested.

EDIT => spelling...yikes! *-(

12
Programming / Re: app high-mem capability, how to tell if it's there?
« on: January 01, 2025, 06:07:11 pm »
Hello Dave!

Happy 2025 to you...

Pretty easy. Marking a random DLL to load high, exehdr outputs,
Code: [Select]
...
Automatic data object:          2

 no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 00001320 00000001 00000002 EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00020000 00000740 00000003 00000001 READABLE, WRITEABLE, 32-bit

OK, cool...I am using the 4.01.003 version here already, and indeed that points to the 'flag' that shows me the current state/mark, thank you, great to know this b/c I've been relying on 'highmem -v' up to now.

Alright...so how about the way the EXE/DLL were compiled??? I thought that in order to enable highmem one had to run a special flag during either the compile or link stages??? Would that not be present somewhere?

That is really what I'm after here...b/c having flipped that highmem flag ON/OFF a number of times, how the heck do I know what the DEFAULT setting was?

I suppose that perhaps this question in a sense dovetails into the following:

1) when should something be marked as 'code' highmem enabled
2) when should something be marked as 'data' highmem enabled
3) when should something be marked as 'both' highmem enabled

For now I am under the impression that anything using 16bit stuff must NOT be highmem enabled, for any of the above settings.

So a more specific example: looking at our Lucide PDF viewer, I see the following for lucide1.dll

1) 'code' marked as highmem
Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

2) 'data marked as highmem
Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit, HIMEM
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

3) 'both' marked as highmem
Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit, HIMEM
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

So it is the different object #s that are impacted, this I can see, but just looking at the details and seeing "...32-bit...", is that sufficient enough for me to consider that highmem safe for any of those combinations?

I am using Lucide as an example b/c I've had a nagging issue with this thing freezing during PDF file opening...sort of a soft-lock...I can usually kill the process, but sometimes it's caused my WPS to shut-down...which is really weird. This typically happens when I'm opening a PDF on the NAS, and very rarely, if ever, when opening a local PDF.

Anyways, since the NAS path is complicated (NetDrive: the plugins, samba stuff, etc.) I am trying to work through that whole stream to confirm that all of it is correctly configured...yeah, kind of a needle in a haystack kind of a thing...LOL!

13
Programming / app high-mem capability, how to tell if it's there?
« on: December 31, 2024, 09:27:43 pm »
...basically, when looking at either an EXE or a DLL, how can I tell whether the application was written/compiled with highmem support?

I am aware of 'highmem', and stuff like 'exehdr', but even in the case of 'exehdr' I do not see how to interpret the results (i.e. is there anything in the output I am missing that already shows me that "yup, highmem capable" flag?).

Yes, I agree that leaving things "as-is" (meaning: the way the software was supplied) is a good recommendation, but if changes were made (we've all marked DLLs to load-high I'm sure) how the heck do I figure out what the intended DEFAULT mode is???

14
Applications / Re: PMInSANE :-P
« on: December 28, 2024, 06:38:17 pm »
Hello Roderick,

..Just a thought why do we not use:
https://www.os2world.com/wiki/index.php/Tame/2
I seem to recall its possible to add scanners to this project ?
Or have I overlooked something ?...

All the best to you in 2025 as well!

To me it's simply a matter of quickness/convenience: Tame/2 is configured and fully functioning here...it's just that too often I simply want to run a quick scan of a page w/o having to fire up the whole "machinery"...lol, so maybe I'm overblowing it a bit, but when all I want is a 600DPI B/W scan b/c I'm going to pipe that through PMView and off to PDFMergeNX...well, so much easier to do this once a REXX custom solution is configured, then to manually repeat the same process in individual applications.

Tame/2 is great for a number of things, such as taking advantage of the ADF feeder on my HP scanner for example, perhaps doing some post-processing for magazine article pages and so on (de-screen), but otherwise it's just 'too big' for about 95% of the stuff I need to do with a scanner.

Subsequently, whether it's Jan-Erik's PMinSANE, or Pete's HPScan, these are much smaller with a sub-set of features you'd find in something like Tame/2 and that's what makes for a quick START=>FINISH workflow.

15
Programming / Re: DISKIO - preferred TIMER to use
« on: December 27, 2024, 07:47:02 pm »
Hello Lars,

You can also use the TIMER$ driver with all its known ill effects (high IRQ load, for example). Question is if that timer will too much interfere with the measurement itself ( decrease I/O performance due to the high IRQ rate of the timer).

Most of this stuff is brand spankin' new to me (as far as actual hands-on code work), however I've done enough reading and doing a few pieces here and there to at least (I hope lol) understand the bigger playing field, point being: my conclusions below may not be spot-on, but I hope at least I'm moving in the right direction.

I looked at the TIMER$ option but concluded, for all the reasons you pointed out above, that this would not be a good option to pursue further given the timing precision needed.

There is an interesting approach highlighted in an EDM/2 article from a few years back: "http://www.edm2.com/index.php?title=High_Resolution_Timing_under_OS/2&oldid=78884" by Timur Tabi that covers this pretty well.

In fact, for me at least it answered (well, almost) the question of "could I pull in the timer information that modern day CPUs already contain, specifically the RDTSC stuff?".

Where I'm a little fuzzy on is whether this API - DevHelp_GetDOSVar, subfunction DHGETDOSV_SYSINFOSEG - can be used in non device driver code???

The example shown in that article is:
Code: [Select]
...
USHORT usrc;                    /* Return Code. */
USHORT TickCount;               /* Number of ticks per call */
void NEAR TimerHandler(void);   /* Callback function */
PGINFOSEG pGlobalInfoSeg;       /* Pointer to Global Info Seg */

usrc = DevHelp_GetDOSVar(DHGETDOSV_SYSINFOSEG, 0, &pGlobalInfoSeg);
...

...but the whole timer topic is waaaaayyyy above my head already!  ???

Pages: [1] 2 3 ... 94