Download link: https://www.noob.software/downloads/silver-v1.4.3.dmg

Silver source: https://github.com/siggi90/NoobSilver MXP source: https://github.com/dbsoft/MXP

This build is no longer available for download.
Release Notes

A very small security update, not going to bother making an experimental version of this.

Well! I just tried to download some add-ons from the Pale Moon add-ons page, and guess what? They have made it so that now you get a button that says "Upgrade Pale Moon" instead of a download button when using White Star.

I guess they want to make a big F*** YOU to anybody who is forking PM? Or staying back with the older version of PM because they want to use Fx extensions?  It's outrageous, and very Mozilla-like of them.

Luckily some of the extensions I need are in other profiles, so I can extract the needed installation files from them, but I shouldn't really have to go to that trouble. And presumably, I won't get any more updates on my Mac since it uses White Star.

And when I don't upgrade on my Windows laptop because I want to keep using Fx add-ons, I won't be able to get the latest PM add-ons etiher.

They are trying so hard to make me throw up my hands and just use another browser.


If this has already been posted to the forum, sorry, I didn't have time to do a search. And needed to vent.

In both WS 29.3.0 and WS 29.4.0.1, I notice that Google Translate is not showing its buttons correctly. I am seeing text instead. Attached is a screenshot. 

   

Built with a more recent SDK and with slightly different build options resulting in performance improvements. Although the titlebar is slightly altered, i hope to change it back in a future release.

Silver source. https://github.com/siggi90/NoobSilver MXP platform source: https://github.com/dbsoft/MXP

https://www.noob.software/downloads/silver-v1.4.2.dmg

I've been trying to migrate my builds over to Big Sur, and so far I've found i had to to do two things: add all the executables in the platform folder to security exceptions in System Preferences. And add: #include <sys/ioctl.h> to _psutil_posix.c

And I've tried building with the Mojave SDK and it builds fine with out errors. However when launching the build in debug mode i get the following error:

Process 86244 launched: '/Volumes/t1_backup/silver_2/basilisk/obj-x86_64-apple-darwin20.5.0/dist/Silver.app/Contents/MacOS/basilisk' (x86_64)
2021-08-19 16:27:04.562747+0000 basilisk[86244:7238718] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=86244
2021-08-19 16:27:04.562938+0000 basilisk[86244:7238718] SecTaskCopyDebugDescription: basilisk[86244]/0#-1 LF=0
2021-08-19 16:27:05.008296+0000 basilisk[86244:7238718] WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.0 instead of 10.16.0. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
Call location:
2021-08-19 16:27:05.008368+0000 basilisk[86244:7238718] 0  CarbonCore                          0x00007fff228be2d1 ___Gestalt_SystemVersion_block_invoke + 112
2021-08-19 16:27:05.008393+0000 basilisk[86244:7238718] 1  libdispatch.dylib                  0x00007fff2024a806 _dispatch_client_callout + 8
2021-08-19 16:27:05.008415+0000 basilisk[86244:7238718] 2  libdispatch.dylib                  0x00007fff2024b98c _dispatch_once_callout + 20
2021-08-19 16:27:05.008436+0000 basilisk[86244:7238718] 3  CarbonCore                          0x00007fff2285fa72 _Gestalt_SystemVersion + 944
2021-08-19 16:27:05.008444+0000 basilisk[86244:7238718] 4  CarbonCore                          0x00007fff2285f688 Gestalt + 149
2021-08-19 16:27:05.008453+0000 basilisk[86244:7238718] 5  XUL                                0x00000001048249fd WebPGetColorPalette + 498691
Process 86244 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffe00002007)
    frame #0: 0x000000010436a084 XUL`___lldb_unnamed_symbol183870$$XUL + 240
XUL`___lldb_unnamed_symbol183870$$XUL:
->  0x10436a084 <+240>: movq  $0x0, (%rax)
    0x10436a08b <+247>: leaq  0x1f30506(%rip), %rax
    0x10436a092 <+254>: cmpl  $0x0, (%rax)
    0x10436a095 <+257>: je    0x10436a0a9              ; <+277>
Target 0: (basilisk) stopped.


Which I'm pretty sure is a codesign problem. My first assumptions are that the privileges are somehow not being granted properly to some executable or script, because I've tried with the exact same configurations as on Mojave but the only different variable being that the build is on Big Sur. I've tried building with verbose mode but i don't seem to see error messages pertaining to ungranted privileges (probably because it just fails silently). Any ideas on what can be done?

On a side note i was also wondering if there's any progress toward building on apple silicon. I took the first steps towards trying it out by using the python script 2to3 to convert everything to python3 but i encountered some errors and eventually after fixing all the explicit errors the most obvious error i got was that the output folder's name was corrupted in that it contained an extra 'b' letter in the name caused by python2 strings being prefixed with 'b's to convert string so to byte strings.

Download SHA256: 7f94a5039575c1c5b5c33102d6dd5ca06620c90180df27215c7a502fdad5e8c2
Source Code GitHub: White-Star MXP (Use branch "Mac" on both repositories)
Release Notes

This version has re-added a fix I put in last year that got wiped out when Moonchild reverted to an older version of NSPR... should improve performance on Big Sur because it can successfully load OpenGL now to enable acceleration.

Update: Minor update 29.4.0.1 to temporarily put FUEL back into the main version as well.

Experimental Build

Download SHA256: 75a66a66e5347771ba9056bb2d309c8894e8aa43c1d5efaed31159d2aa81cdb9

This experimental build is a bit different from the last one, it has the dual system and FUEL put back... and built with gamepad support. So it should be able to run old Firefox extensions.  The previous version additionally had WebRTC enabled, but it appears WebRTC support needs to be updated to support the new version of libcubeb.  I haven't delved into it yet, but it appears to be an upstream problem, so not sure if I should work on it myself or not... I'll investigate further and if possible release an updated experimental build with WebRTC when I can.

Brian

=== Code Style and Design ===

--- Design Principles ---

To explain the existing style and where we are going it makes sense to explain the history of Dynamic Windows.  There are several design principles that Dynamic Windows adheres to:

1) Compatibility, Portability

C was chosen as the API because essentially every platform has a C compiler.  Even when the internals are written in another language, like C++, Objective-C or Kotlin/Java, the exported API is portable C that can be used on all the platforms.

2) Light-weight

C is also one of the most light weight languages making it a good choice here too.  We leverage the native APIs on the platform to reduce the Dynamic Windows footprint.  Only implementing our own widgets or functionality when the target platform has no native support.

3) Native

While the C API hides all the internals for a platform from the developer behind typedefs and API calls, the native system functionality is just below the surface.  Platform specific #ifdefs can allow you to use native system calls to augment Dynamic Windows functionality. 

This was a bit more simple in the past when all the system APIs were in C, but it is still possible with systems like Mac and iOS where the internals are in Objective-C, an intermediary source file may be necessary to call native code.

4) Easily embeddable

The core Dynamic Windows functionality should be encapsulated into a single file when possible.  The idea is that including Dynamic Windows in a project should be as simple as adding the dw.h header and the target platform core source file into your project.

5) Simplicity

It should be fairly simple to write a modern and functional interface even when using a fairly low level language such as C.  We accomplish this by encapsulating the complexity in the library behind a simple API.  Using the box packing, signal handling and object data functionality that are the center pieces of the API.

--- History ---

These principles were critical in the first Dynamic Window use case, it was used to write a graphical self-installer for OS/2 (and later, Windows and Unix).  The executable header needed to be compact, and able to function with a minimal system install.  Later scripting support was added using the built-in system scripting language REXX, which was also ported to the other platforms using Mark Hessling's Regina REXX interpreter.

Dynamic Windows was then built as a Dynamic Link Library or Shared Object to be used in more standard applications, including my HandyFTP application which was originally written with the Cell Toolkit on OS/2, the graphical versions of the BitchX IRC client and various other private applications.

In those early days not much thought was given to namespace pollution, or consistency for the internals, as long as the public APIs were exported and things compiled and worked things were good.  As time marched on, code was acquired from other sources or contributed by people to the project and the internal naming got more and more random.

At some point I became aware that on Linux, shared libraries basically exported all symbols by default, when I ran into an odd symbol conflict issue in an application I was working on.  When built as DLLs on OS/2 and Windows this was not really an issue, since exports at the time were explicit in the export definition file.  The experience on Linux however, made me think about the naming of global functions and variables, which caused me to start adding an underscore _ to any internal functions in an attempt to avoid conflicts. I did this on all platforms, since one of the design principles was embedding and in that use case even OS/2 and Windows can have name conflicts.

When I came back from a break from working on Dynamic Windows, I started using _dw_ as the prefix to my internal functions, since while I have never actually run into an issue with an underscored function or variable colliding, it is possible that another library could be using underscores to do the same thing that we were.  Therefore for visual consistency and as an added layer of protection the _dw_ prefix seemed like a good idea.

During the 3.2 release cycle I have been effectively writing 3 new platforms simultaneously, one from scratch (Android) and two based on existing code (iOS based on Mac and GTK4 based on GTK3 and Mac).  I began thinking about making things work and look the same on all the platforms.  I tried to keep them all functioning similarly and in essentially the same style when possible, which is great for these new platforms but it caused them to diverge from the existing platforms.  So I decided to go back and start updating the old existing platforms with the style choices I made with these new platforms, and it became obvious I should document and have discussions with users about these changes.

--- Style in the 3.2 Release ---

- Public -

These functions, types and constants are part of the portable C API, usable by everyone on any platform.

Function prefix: dw_ (lowercase)
Handle type prefix: H  (uppercase)
Structure prefix: DW (mixedcase)
Constant prefix: DW_ (uppercase)

- Internal -

These functions, variables and constants are used only inside Dynamic Windows, or the platform they are defined in.

Function prefix: _dw_ (lowercase)
Variable prefix: _dw_ (lowercase)
Constant prefix: _DW_ (uppercase)

- Native -

These non-C classes (Objective-C or C++) or variables are platform specific and can be used inside a platform #ifdef

Class prefix: DW (mixedcase)
Variable prefix: DW (mixedcase)

There are at least two functions that are sort of exceptions to this, _dw_init_thread() and _dw_deinit_thread() are two internal functions that are exported for use in language bindings such as Google's Go.  Plus at the time of this writing I have not finished the code audit, so there may be some that have not been changed yet to match this scheme or due to possible compatibility problems.

Also the Kotlin code for Android does not follow this naming system, but to access the Kotlin APIs you need to call it via JNI, so there are no namespace issues.  However it may make sense to have non-C code style guidelines added to this document at a later date.

--- 3.2 Release C Coding Style Guidelines ---

Due to the base API being in C, it brings lots of compatibility but also many pitfalls.  Writing applications in C brings memory handling and variable management pitfalls.

We have tried to handle these issues by providing access to the C memory and string functions when including dw.h and providing a virtual method of storing data on window/widget handles with the dw_window_get_data() and dw_window_set_data() APIs.  This allows you to avoid creating global variables, and instead save data on the window handles, along with macros for converting types such as: DW_POINTER_TO_INT() and DW_INT_TO_POINTER().

Ideally globals should only be used for data that is truly global, settings and such.  Windows and other handles should be context specific, created in dwmain() and then destroyed when leaving dw_main().  Any window specific data should be saved on the window handle with dw_window_set_data() then accessed with dw_window_get_data() in the callbacks using the window handles passed.

The dwtest application should be updated in the future to adhere to these guidelines, but since it was originally written ages ago it is not an example of a modern Dynamic Windows application.  Dynamic Windows Interface Builder should be looked at for modern Dynamic Windows coding style.

Thanks for reading!
Brian

Silver source: https://github.com/siggi90/NoobSilver MXP source: https://github.com/dbsoft/MXP

Download link: https://www.noob.software/downloads/silver-v1.3.0.dmg

For those who don't know Silver is a macOS port of Basilisk (another XUL based web browser), which supports XUL extensions. Silver, like White Star, uses DBSoft's MXP platform

This build is no longer available for download.
Release Notes

The Pale Moon team surprised me by releasing 29.3.0 a day early, their official release day is Tuesday. I had set aside Monday and Tuesday from my schedule to cherry pick all the changes, test and release... I got the cherry picking done, but not the testing.  So I am releasing with minimal testing right now, will test tonight and tomorrow and if necessary release updated builds.

Also, if anyone wants to donate to any of my projects, I am trying out a Patreon site for it, since a few of my friends' projects have been using it, why not try?

Enjoy!
Brian