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 - Dave Yeo

Pages: 1 [2] 3 4 ... 223
16
Networking / Re: Squid Cache
« on: January 22, 2022, 05:12:14 pm »
Hi Harald, unluckily given Intel's crappy naming, Xeon doesn't say much besides being the high end of whatever Intel was making. Seems "000D7A99 >FISTTP QWORD " is SSE3 and I guess your CPU doesn't support it and is pre-Prescott if I understand it right.
Attached is cpuinfo.exe, that'll list your CPU characteristics if you want to post them.
Paul can comment on whether this was assembly or C code.

17
Networking / Re: Squid Cache
« on: January 22, 2022, 06:08:11 am »
In theory, on a client, especially one with a bad/slow connection, using the cache speeds things up as many responses come from the cache instead of over the internet. It was why I used squid when I was on dial up. In practice I found less and less benefit as things went to HTTPS as it is hard to cache encrypted content and stopped using it.

18
Networking / Re: Squid Cache
« on: January 22, 2022, 03:59:23 am »
Hi David, setting it up in SeaMonkey should be a matter of going to Preferences-->Advanced-->Proxies and choosing Manual Proxy Configuration and entering your address, 127.0.0.1 was what I used for squid along with the port number, 3128? It's set in squid.conf.
Might need to add your hostname to squid.conf, I had,
Code: [Select]
#Default:
# Automatically detect the system host name
visible_hostname bluelion-40654
During the bluelion days.

19
Networking / Re: USB Modem
« on: January 22, 2022, 03:51:04 am »
Another thing was that using the Injoy dialer's NAT, I had to kill socktidy or not load it. IIRC, all it needed was the basic ATZ to initialize it.

20
Networking / Re: USB Modem
« on: January 22, 2022, 03:42:42 am »
Yes, I used those while stuck on dial up. Only the Arca Noae USB drivers worked with it and they're very sensitive to lightning, I went through two. Luckily they were cheap at the local drug store due to being discontinued.
Actually might have been a different modem that only worked with the Arca Noae USB drivers. Anyways other then the lightning problems, they were fine on my crappy landline. IIRC, you do have to install the supporting USB drivers.

21
Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 21, 2022, 05:25:42 pm »
But it would be great if we could port webrtc to work on our platform.

Well, QT5's web engine also supports webrtc, which I guess is what BWW is planning on enabling. For Mozilla, it would require someone who knows what they're doing. Hopefully BWW will solve the remaining problems with the new browser.

22
Networking / Re: Squid Cache
« on: January 21, 2022, 08:13:09 am »
Hi Harald, SIGILL is a bad instruction, usually from targeting a newer processor then the one you're using. What CPU do you have? And what is the failing opcode, be the section "Failing instruction" in your trp report just below the part you quoted.

23
Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 21, 2022, 07:41:29 am »
Yes, but how does the video (and audio) stream get to an application such as a web browser? And how does the application control the camera (perhaps focus for example), get capabilities and such? It does look like Mozilla will handle the transcoding and likely the muxing
Guess I could enable webrtc and see where the compile breaks.

24
Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 21, 2022, 02:03:06 am »
WebRTC is probably the solution for video conferencing. QT5 supports it, as well as our Firefox. Of course it needs to be coded for our platform and currently as far as I know, only USB audio supports microphone input.
https://webrtc.org/

25
Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 20, 2022, 11:47:07 pm »
I also think WiFi would be a high priority. Both WiFi and dual screen have been mentioned by Arca Noae on their roadmap.

I'd add an item that is partly software and partly hardware -- I'd like to see video conferencing on our platform. This also seems to be in progress, but at BitWise and in discussions here. That is both audio and video hardware.

Funny enough, the video support is better under VirtualBox then it is on plain HW. My built-in notebook webcam is detected in VirtualBox as a USB video device with bulk endpoint. The combination of libuvc+libusb has no problems using it. What we now need is a port of a Linux web app based on QT (for display) and  livuvc+libusb (for the data streaming). I am not yet clear about audio (synchronized to video).
The OS/2 MMPM subsystem is built upon streams that can be synchronized. But if you use libusb + libuvc, they know nothing about the OS/2 MMPM streaming (manager). You just read video and potentially audio directly from the device but then, these are not synchronized.

Lars

Usually the video and audio are compressed and muxed into a container, AVI, Matroska(webm) etc with syncing happening there. FFmpeg or libavcodec can handle that.
It also raises the question of licensing and such. If something is expecting H264 and AAC, well they're patented. There's libvpx, vorbis etc, does any video conferencing software support them?

26
Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 20, 2022, 03:00:04 am »
Yes, I set it with NO_ERROR. At first I was worried about the scope of rc as it is used throughout the file.  Though thinking about it, I'm not sure what happens if there is an error, whether in the memory allocation or what DosQueryPathInfo() returns, perhaps it should have been passed somehow to the class, nsLocalFile::SetPermissions(uint32_t aPermissions).
https://github.com/bitwiseworks/mozilla-os2/blob/master/xpcom/io/nsLocalFileOS2.cpp about line 1931

27
Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 18, 2022, 06:47:02 pm »
Thanks, that worked, except the EA's are still there. Probably need to strip them later when the tmp file gets moved to the permanent name in download.cpp

28
Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 18, 2022, 08:01:05 am »
In my QE editor and a few other programs, I simply make sure that new files are created without EAs. 

More precisely, because libc creates these file permission EAs on a new file automatically, my save routines all have some logic to immediately delete them if the file was new. (I don't do that when updating an existing file because the user might actually have set them on purpose.)

e.g.
Code: [Select]
    if ( !fileExists ) {
#ifdef __OS2__
        // If this is a new file, get rid of the useless default EAs added by klibc
        deleteEA( pszFileName, (PCSZ) "UID");
        deleteEA( pszFileName, (PCSZ) "GID");
        deleteEA( pszFileName, (PCSZ) "MODE");
        deleteEA( pszFileName, (PCSZ) "INO");
        deleteEA( pszFileName, (PCSZ) "RDEV");
        deleteEA( pszFileName, (PCSZ) "GEN");
        deleteEA( pszFileName, (PCSZ) "FLAGS");
#endif
    }

Code: [Select]
unsigned long deleteEA( char *pszPathName, const char *pszEAName )
{
    PFEA2LIST pFEA2List = NULL;
    PFEA2     pFEA2 = NULL;
    EAOP2     eaop2 = {0};
    size_t    cb = 0;
    APIRET    rc = ERROR_NOT_ENOUGH_MEMORY;

    cb = sizeof( FEA2LIST ) + strlen( pszEAName );
    pFEA2List = (PFEA2LIST) calloc( cb, 1 );
    if ( pFEA2List ) {
        pFEA2List->cbList = cb;
        pFEA2 = pFEA2List->list;
        pFEA2->cbName = (BYTE) strlen( pszEAName );
        strcpy( pFEA2->szName, pszEAName );
        pFEA2->cbValue = 0;

        eaop2.fpFEA2List = pFEA2List;
        rc = DosSetPathInfo( (PCSZ) pszPathName, FIL_QUERYEASIZE,
                             (PBYTE) &eaop2, sizeof( eaop2 ), DSPI_WRTTHRU );
        free( pFEA2List );
    }
    return (unsigned long) rc;
}

Well, so far I've come up with this,
Code: [Select]
diff --git a/xpcom/io/nsLocalFileOS2.cpp b/xpcom/io/nsLocalFileOS2.cpp
index 32715473bd..bb772a8053 100644
--- a/xpcom/io/nsLocalFileOS2.cpp
+++ b/xpcom/io/nsLocalFileOS2.cpp
@@ -16,6 +16,7 @@
 #include "nsIDirectoryEnumerator.h"
 #include "nsIComponentManager.h"
 #include "prlink.h"
+#include "prmem.h"
 
 #include "nsTraceRefcnt.h"
 #include "nsReadableUtils.h"
@@ -233,6 +234,32 @@ static int isleadbyte(int c)
     return retval;
 }
 
+static nsresult deleteEA( char *pszPathName, char *pszEAName )
+  {
+      PFEA2LIST pFEA2List = NULL;
+      PFEA2     pFEA2 = NULL;
+      EAOP2     eaop2 = {0};
+      size_t    cb = 0;
+      APIRET    rc;
+
+      cb = sizeof( FEA2LIST ) + strlen( pszEAName );
+      pFEA2List = (PFEA2LIST) PR_Calloc( cb, 1 );
+      if ( pFEA2List ) {
+          pFEA2List->cbList = cb;
+          pFEA2 = pFEA2List->list;
+          pFEA2->cbName = (BYTE) strlen( pszEAName );
+          strcpy( pFEA2->szName, pszEAName );
+          pFEA2->cbValue = 0;
+
+          eaop2.fpFEA2List = pFEA2List;
+          rc = DosSetPathInfo( (PCSZ) pszPathName, FIL_QUERYEASIZE,
+                               (PBYTE) &eaop2, sizeof( eaop2 ), DSPI_WRTTHRU );
+          PR_Free( pFEA2List );
+      }
+      if (rc != NO_ERROR)
+        return ConvertOS2Error(rc);
+  }
+
 //-----------------------------------------------------------------------------
 // nsDirEnumerator
 //-----------------------------------------------------------------------------
@@ -1956,6 +1983,15 @@ nsLocalFile::SetPermissions(uint32_t aPermissions)
 
     pathInfo.attrFile ^= FILE_READONLY;
 
+//  Get rid of the useless default EAs added by klibc
+    deleteEA( mWorkingPath.get(), (PCSZ) "UID");
+    deleteEA( mWorkingPath.get(), (PCSZ) "GID");
+    deleteEA( mWorkingPath.get(), (PCSZ) "MODE");
+    deleteEA( mWorkingPath.get(), (PCSZ) "INO");
+    deleteEA( mWorkingPath.get(), (PCSZ) "RDEV");
+    deleteEA( mWorkingPath.get(), (PCSZ) "GEN");
+    deleteEA( mWorkingPath.get(), (PCSZ) "FLAGS");
+
     rc = DosSetPathInfo(mWorkingPath.get(), FIL_STANDARD,
                         &pathInfo, sizeof(pathInfo), 0UL);

But the compiler isn't happy with converting the strings, (also the return type)
...
Code: [Select]
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:1993:31: error: invalid conversion from 'const char_type*' {aka 'const char*'} to 'char*' [-fpermissive]
 1993 |     deleteEA( mWorkingPath.get(), (PCSZ) "FLAGS");
      |               ~~~~~~~~~~~~~~~~^~
      |                               |
      |                               const char_type* {aka const char*}
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:237:33: note:   initializing argument 1 of 'nsresult deleteEA(char*, char*)'
  237 | static nsresult deleteEA( char *pszPathName, char *pszEAName )
      |                           ~~~~~~^~~~~~~~~~~
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:1993:35: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1993 |     deleteEA( mWorkingPath.get(), (PCSZ) "FLAGS");
      |                                   ^~~~~~~~~~~~~~
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp: In function 'nsresult deleteEA(char*, char*)':
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:261:3: warning: control reaches end of non-void function [-Wreturn-type]
  261 |   }

Ideas?


29
104b should be on the ArcaOS install ISO,
Code: [Select]
I:\OS2IMAGE\DEBUG\SMP>bldlevel os2krnl
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:14.104b#@_SMP  IBM OS/2 Kernel
Vendor:          IBM
Revision:        14.104
File Version:    14.104
Description:     _SMP  IBM OS/2 Kernel

30
...
The system detected an internal processing error at
location ##0168:a41c - 0010:a41c.
60004, 6009
128606c3 - 00/00 00:00:00.00
Internal revision 14.104b_SMP
The system is stopped.  Record all of the above information and
contact your service representative.
...

That 14.104b_SMP is a very old kernel, in fact the quasi-official latest IBM build was 106. AOS has gone to never kernels since, and that might help.

Isn't that the newest debug kernel? Ok, I see there may be a 14.104c SMP floating around.

Pages: 1 [2] 3 4 ... 223