David Schwartz

Switch to VirtualBox perhaps?

I'm trying again with this, and am still getting the same errors.

There is a flag in compiler settings that is checked globally. (See attached image that shows it's checked.)

The FAQ and several other places say this is related to the compiler thinking that I'm using Runtime Packages, which I AM NOT. (See second attached image below.)

The HELP info on it just says this:

[dcc32 Error] E2201 Need imported data reference ($G) to access 'IsMultiThread' from unit 'FastMM4'

(*$IMPORTEDDATA ON*)  <<----
unit u0;

{Set this option when you use runtime packages in this application or library.
 This will automatically set the "AssumeMultiThreaded" option. Note that you
 have to ensure that FastMM is finalized after all live pointers have been
 freed - failure to do so will result in a large leak report followed by a lot
 of A/Vs. (See the FAQ for more detail.) You may have to combine this option
 with the NeverUninstall option.}
{$define UseRuntimePackages}

{-----------------------Concurrency Management Options------------------------}

{Enable to always assume that the application is multithreaded. Enabling this
 option will cause a significant performance hit with single threaded
 applications. Enable if you are using multi-threaded third party tools that do
 not properly set the IsMultiThread variable. Also set this option if you are
 going to share this memory manager between a single threaded application and a
 multi-threaded DLL.}
{$define AssumeMultiThreaded}

8 hours ago, Pat Foley said:

To bring it up to 486 spec here's this 
https://chapmanworld.com/2018/02/09/lockless-multi-threading-in-delphi/

   

I'm not sure what this has to do with the 486, but I would not use that solution as it can be interrupted and its state changed.

The whole purpose of critical sections is that they extend a simple atomic operation to span several instructions by using a protocol that can be safely interrupted. The only other option is to disable interrupts, but even then the CPU usually has a "high-priority interrupt" that can still interrupt the execution flow. This is exactly how some of the hacks worked that used the look-ahead cache on Intel's CPUs a few years back.

We were creating something that had no OS support. Turbo Pascal (and later Delphi) are designed to work inside of DOS and/or Windows. Both of these OS's supports critical sections, but they're only valid for stuff running entirely within the OS. 

When you're reaching out across a bus (or, today, the internet) to an asynchronous process in an unknown environment, all bets are off.

Anybody who remembers the TSRs that ran in DOS knows they did not run within the OS context (even if you consider DOS an actual OS). Nor did most of the device drivers for DOS, or even Unix for that matter.

We were working with a fully interrupt-driven OS where everything was managed within the OS. What this project did was gave us a way to extend a reliable communication channel across a data bus, sometimes through shared memory, with a peer on the other side, without having to know anything about what was running on the other side. We actually based it on the first 3 layers of the ISO networking model. 

By the time the 80486 family hit the scene, the boards using smaller, slower CPUs were retired, and the hardware was updated to make this easier. I'd left the company by that point. (laid-off)

10 hours ago, Alexander Elagin said:

A small correction: 8080 has a 16-bit address bus and a 8-bit data bus (I am currently building a retro computer based on 8080A + 8224 + 8257 + 8275 + 8255A). 8085 also had a 16-bit address bus but it was multiplexed with the 8-bit data bus and required an additional latch for full address decode. Otherwise, your post was outstanding and very informative, thank you!

Thanks for the correction. I guess it was the 8008 with the multiplexed 8-bit Addr bus. It has been a long time since I looked at any of that stuff. The 8085 was a bit odd. It had a bunch of additional instructions added to it that were more-or-less duplicated on the Z80, but at the last minute they decided not to publish them. They were implemented in the first couple of production runs, but then they were removed. So only a couple of new instructions showed up on it that were mainly for controlling something.

14 hours ago, Fr0sT.Brutal said:

To me this seem useless. If devices are linked into a network they're usually controlled by UI of a head unit or by an app (hi Xiaomi). If they're individual, they rarely require rich UI - raising Delphi server+uniGUI on a "smart" bulb just to change its color... rather silly. With all these messy JS frameworks classic nginx+PHP+user-side static pages are unfairly forgotten but they're still the best choice for simple admin consoles

Well, if you look at everything Delophi produces as a "rich UI" and dismiss using Delphi to build even "dumb forms" then I guess your "classic nginx+PHP+user-side static pages" is going to look much simpler.

I built this in WebCore in about an hour. It's far from what I'd consider a "rich UI" although there's a lot that could be done to spiff it up. It's not the kind of thing I'd use WebCore + Miletus to build for an IoT device, but it shows the power available using Delphi to build browser-based web apps.

http://bestkeywordmixer.com

The JS file for this is 1.8 MB in size (debug version), which is comparable to the size of the standalone Delphi EXE. The Miletus core is just shy of 8MB.

Their example demo app is a weather thing that displays the temperature, humidity, and barometric pressure on your device. They built an iOS app to display it in an iPhone to demonstrate the REST API, although it would work just as well running it in the browser.

I don't know ... maybe it could be used to remotely turn some lights on and turn up the heat in the house as you're leaving work to come home, then open the garage door as you approached. I don't find that terribly useful.

However, if you're doing data collection and/or running some kind of equipment from remote devices, it could be very helpful to allow you to manage them remotely. 

14 hours ago, Rollo62 said:

From my understanding of Miletus, it uses the standard OS browser anyway, so its just an option to make the web-app "installable".

The additional advantage of Miletus I see is, that it could open and add certain features to a web-app, that wouldn't be possible for a pure browser.

(Like IO/ access or controlling specific hardware, also time-critical tasks, or the like).

To make that option real, TMS would have to open Miletus, best of all as open source, so that it could be easily extended when needed.

That would be a real advantage over Electron.

The web-app runs as a js script inside the browser. If you close the browser then reopen it, or navigate away, it's gone. Nothing is persistent. And nothing is running on the site where it was loaded from.

However, there does seem to be a back-door they provide on the server it came from that's embedded in the Miletus platform that lets the app running remotely connect with resources on the server. 

I imagine they will eventually open it up, but for now it's not. They're still probably making changes that they don't want to proliferate by opening it up early.

I don't know diddly about Electron other than some stuff I read that indicates it's extremely bloated with lots of stuff that's not needed all the time. Miletus was inspired by Electron, but is apparently quite slimmed-down.

Very innovative IMHO!

10 hours ago, Andre Capelli said:

the server send 3 posts with {"leads": [{json}]}, {"leads": [{json}]}, {"leads": [{json}]} in the same moment, how to control that at the same time?

I'm not all that familiar with JSON, but looking at this and what you're saying, I'm wondering if this shouldn't be structured as an array?

"a_lbl1": [  {"leads": [{json}]}, {"leads": [{json}]}, {"leads": [{json}]}  ]

17 hours ago, Lars Fosdal said:

Personally, I would not want to spend limited resources on an IoT unit on hosting a complex UI.

It's just a payload loaded by the HTML page -- a chunk of javascript and maybe some images and icons, which could just as easily be hosted elsewhere if need be. 

Funny that I don't see comments like this about the plethora of js libs that average web pages haul in just to make pretty buttons and combo-boxes.

Not sure the difference between a "complex UI" and something less complex is going to be significant given the amount of scaffolding needed to host the VCL.

That issue aside, it still doesn't answer my question about what use-cases you can think of for this technology on IoT devices.

17 hours ago, Lars Fosdal said:

/off-topic
Still a double use in the title.

Sorry, I don't see any.

17 hours ago, Lars Fosdal said:

I'd be curious to see the resource requirements of a Miletus app.

Bruno said it's a hair under 8MB. But I don't know if that includes the code needed to emulate the VCL library.

10 minutes ago, Lars Fosdal said:

/off-topic

Your post title needs a little tweaking, me thinks. 
It is Miletus, not Melitus (which is diabetes).

fixed. thanks.

10 minutes ago, Lars Fosdal said:

Many industrial units have web interfaces built in - but these are one more attack vector - and if you are rolling your own - there is the issue of maintenance and even more stuff to deploy to the devices. Personally, I would not want to spend limited resources on an IoT unit on hosting a complex UI.

 

Yes, it can be done this way - but - should it be done this way?

Valid question, but this isn't my product. They built it because their users asked for it.

Maybe we're saying similar things. I'm curious what use-cases there are besides admin panels.

That said, if you're proficient in Delphi, it may be much faster to build something in Delphi than a static web site builder. And if there's any logic required behind the scenes, then the complexity of the traditional approach just doubled or tripled because you'll need to use another language (eg, js, python, php) for that purpose.

I'm reading this debate and it triggers a lot of memories from a project I led in the first job I had out of college. I also searched for that TInterlocked.CompareExchange function and found quite an interesting discussion on SO that reminded me that we're really lucky there was a bug in Intel's 80286 chip that killed their protected-mode OS efforts and actually derailed their whole segmented memory architecture.

I hope some of you enjoy this. For the record, this all happened in the 1979-86 time-frame.

There's also something useful here related to this thread.

================================================================

In my first job out of college, I was hired to work at an Intel facility that created and built their line of Single Board Computers (SBCs) that used their MultiBus backplane. (It was an industrial design; most people are familiar with the analogous but much simpler S-100 bus that IBM introduced in their PCs.)

I was assigned a simple project one day: to write a driver for their 8-bit real-time embedded OS (RMX-80) that ran on an SBC with an 8-bit CPU (8080 or 8085) and talked with another SBC that simply had four UARTs on it (UARTs are 8-bit serial communication devices, aka "comm ports") used for RS-232 connections. The code itself had to fiddle with things via the IN and OUT instructions because Intel's chips infamously did not do memory-mapped IO like Moto's 6800, or the 6500 used by Woz in the first Apple computer.

I talked with a hardware guy and was assured this was safe to do because the MultiBus ensured one clock cycle atomicity. So we could have an 8080 or 8085 board with any number of these 4-port serial controllers plugged in, and run IN and OUT (single-byte I/O) instructions to get and fetch data from/to each UART on each serial card using different 'ports' and there would be no need to deal with locks. YAY!

One weekend, some guy in Marketing started noodling around and made a grid with all 27 of the boards we made and that were in development listed along the X and Y axes, and in the intersecting cells he made an 'X' if it made sense for the two boards to communicate. Then he decided it might be a Good Idea to make this a more generic solution and took it to a Product Planning Committee.

A couple of weeks later, I was informed that my "simple" project had just been considerably expanded. It was renamed "Multibus Message Exchange" or "MMX" for short. And yes, if "MMX" seems familiar, it was recycled years later for something completely different. The original thing got absorbed into their OS designs and eventually became obsolete. 

Here's where it gets interesting (and quite boring if you're not familiar with computer hardware)...

We had SBCs that had a variety of CPUs on them: 8080, 8085, 8086, 8088, 80286 (in development) and 80386 (still being defined). 

Each CPU has two busses: an Address bus and a Data bus. The 8080 and 8085 had 8-bit busses for both. The 8086 and 8088 had a 16-bit Addr bus; the 80286 had a 20-bit Addr bus; and the 80386 was planned to have a 32-bit Addr bus. 

Meanwhile, the 8080, 8085, and 8088 had an 8-bit Data bus; the 80286 had a 16-bit Data bus; and the 80386 had a 32-bit Data bus.

The Multibus had both 16-bit Data and Addr busses. With the pending design of the 80386, they widened the Multibus to support 32-bit Data and Addr busses.

Some of the boards also had 8048 MPUs on them (the chips that were in early PC keyboards) that were also 8-bit devices, eventually replaced with 8051 chips.

Also, some had "shared memory" on them, which was a big block of memory where the address on the outside looking in (from another board with a larger address space) was almost always different than what the code running on that board's CPU saw on its end. 

If you're keeping score of combinations, we're at a pretty big number for such a simple idea.

This thing that started out as a simple little project now had to support the ability to send messages from one OS on one CPU to a possibly different OS on a different CPU; sometimes using shared memory that had a different address range on either side; where they both could have different sized data and address busses; and the MultiBus backplane itself could not be locked for more than one clock cycle.

They were working on a "smart 4-port UART" board that had an 8085 controlling the four UARTs and 16 KB of shared memory. The 8085 had a 16-bit (64KB) address space, but the OS ran in a ROM that was hardwired to the first 16KB because when you grounded the RESET pin momentarily, it reset the CPU and set the IP to start executing at address 0. 

Needless to say, when you had a 16-bit or 32-bit data bus on one side and the other only had an 8-bit data bus, this caused a problem because the data could only be seen one byte at a time on one side, but it was 2 or 4 bytes wide on the other. It was also impossible to pass pointers between boards with CPUs on both sides. This made memory-mapped I/O highly problematic, which I think is one reason Intel went with the IN and OUT instructions instead.

This mess was due in part to the fact that the MultiBus only had one clock cycle atomicity. We could not write 16-bit or 32-bit values to a shared memory address and ensure they would be received without getting corrupted because the shorter receiving side had to do multiple reads, which toggled the MultiBus' clock with each read. (Until this point, the engineers had no reason to design an 8-bit board to read 16- and 32-bit wide data and multiplex it into a series of 8-bit data bytes.) <sigh>

If anybody remembers the old "small", "medium", "large", and "compact" memory models in old Intel compilers, this is part of what those designations were intended to address. It was a frigging nighmare. Those model designations first showed up while I was working on this project, and we got an updated compiler with a note about this apologizing that it was the only way to deal with the segmented memory model in the 80286 other than forcing everybody to use the same model, which was totally unworkable. 

We BEGGED the engineers in charge of the Multibus to add an explicit LOCK signal to it so boards with mis-matched data and/or address busses could have something to ensure that an INTEGER of ANY WIDTH could be transferred atomically across that damned bus that they loved to extoll was "the most advanced bus in the industry!" We succeeded in getting the Product Planning Committee to take it up for discussion, and they agreed, but they chose not to go back and fix any existing boards -- it would only be implemented going forward. Meaning we were stuck having to deal with that mess on all of the existing board combinations they decided needed to be supported. Ugh.

---------------------------------------

I did a ton of research and stumbled upon something that someone at IBM had just published in one of their journals that seemed to anticipate our exact situation. It was a short article that simply explained a reliable way of building a lock or semaphore without any hardware support. All it required was an atomic TestAndSet that worked on both sides with at least one bit. We had atomic byte-sized TestAndSet operations that worked everywhere, so that's what we used.

TestAndSet reads the value of a memory location and returns its value, and writes a 1 into that location, in a single atomic uninterruptible action.

Most semaphores issue a lock, try to grab a flag, then either proceed or release the lock and try again.

In this case, a lock isn't needed. It's done through a protocol that everybody follows.

You do a TestAndSet, and if the value returned is 1 then you sleep for a bit and retry until you get it.

If you get a 0, then you do it again on a second location.

If you get back a zero the second time, then you have a green light to proceed. If not, you clear the first flag, sleep a bit, then try again with the first flag.

When you're done, you clear the second flag, then clear the first flag.

For us, this was like cutting the Gordian Knot! 

(The paper went into a bunch of details about why this works realiably. I don't recall them.)

=========================================================================

PS: if you're read this far, I'll let you in on a little secret related to this that very few people know about the history of the 80286 and the bug that kept it from working in protected mode... 

The 80286 architecture was created by some guys from Honeywell that were trying to build a simplified version of their Multics secure computing system. Part of the magic was that the OS had some support in the hardware. Our OS guys worked closely with the chip designers to ensure that the 80286 chip supported all of the magic stuff that the OS needed to be secure. They had a big meeting and everybody signed off on the chip design and the chip guys went off to build it while the OS guys started working on the fancy new OS. I was hired a few months after that meeting to work on that very OS.

Our hardware guys had been working in parallel to design a MultiBus SBC that they could drop the 80286 chip into and it should just work. 

For new chip designs, Intel would first create an In-Circuit Emulator (ICE) that they'd use for hardware testing. We got some of them and they worked properly as expected.

But when we finally got the first prototype chips, they failed some tests. We sent the results back to the chip guys and were told "we're working on it" for months. We got back a couple more iterations of 286 chips and they fixed some problems, but one seems to persist.

Apparently, after the final meeting and agreement on the chip design, the chip guys built the ICE units based on that design, but then decided to optimize something in the microcode and made some changes in the on-chip wiring that simplified a bunch of other logic, and they never ran it by the OS team. They also didn't update the ICE unit's design to reflect these changes, believing they were simple "refactorings" that would have no side-effects. They kept dodging the OS team's attempts to meet and help with this. When the OS team finally got their hands on the T-Spec, they went ballistic, because the chip guys basically broke the security model with their "refactoring".

Seems that what they did caused the CPU's Stack PUSH instruction to be non-atomic when the chip was running in "protected mode". Meaning that if an interrupt came in while an address was being pushed onto the stack, it could be interrupted after the segment register (16 bit base index) was pushed onto the stack, but not the 16 bits (offset part) of the IP -- because they came from different registers. The result was that when the interrupt popped the return address off the stack, it got the segment register value, but the next word was NOT the IP address. Obviously, it went off into the weeds and typically generated an address fault. Unfortunately, they decided they couldn't fix it without delaying the chip's release by 6 months or so. That was getting too close to the release of the next chip, the 80386, so they decided to accelerate the release of the 80386 instead and wave-off use of "protected mode" in ALL 80286 designs. (Customers were not happy!)

In fact, IBM and some other companies (besides us) had been working very diligently to build a secure OS that was supposed to run on the 80286 in "protected mode". But the 286 never worked in "protected mode" because they never fixed this problem. When we released the 80286 chip, IBM and others sold an upgraded OS that ran on it, but not what they had planned.

The 80386 was released earlier, but nobody ran it in "protected mode" either because that required the segmented memory model which everybody HATED.

The 80386 was supposed to have a bunch of new features, and only ended up with a few in order to get it out the door faster. But the one that captured the industry's attention the most was its support for a "flat memory model". That was the point where Intel threw in the towel and shifted entirely to a "flat memory model", doing away with all of those crazy "small", "medium", "large", and "compact" compiler models and all of that nonsense that came with a segmented addressing scheme. (Never mind that it was actually modeled after IBM's mainframes, which is one reason IBM loved its design.)

Ok, now get back to work!

This is a bit OT, but I'm curious about something. TMS WebCore now has a Miletus option that lets you build apps that run on Raspberry Pi hardware. 

I don't have a complete picture of what the Miletus wrapper does, but it's very similar in function to what Electron does.

My notion of it is that it's not much more than a web server that serves up an app written in Delphi that has been translated to javascript -- you have an HTML page that has a SCRIPT tag in the header that loads it into the browser where it runs.

If you did this more conventionally, it would be something like, say, a python scriopt running in a REST service that was controlled by a remote app. I don't know if you'd need a separate REST server running with a Miletus-hosted WebCore app.

But I guess the part in the browser communicates with something on the other end that allows you to "write-thru" to control things on the device.

A use-case that springs to mind most immediately for me is using it to implement some kind of "admin" panel for whatever is running on the device. These devices are generally headless anyway, so it solves that problem.

Eg, you could have an app written in whatever that controls something, and you might want a UI-based admin panel to adjust settings. This would be perfect for that purpose. (Think of connecting to your router or printer directly to adjust settings on them.)

If the device in question has BT or a WiFi connection, then it could communicate with and control other remote devices, and also control stuff directly using its built-in I/O pins. 

I'm just curious what other ideas for use-cases others might have for controlling IoT devices via a remote app like this running in a web browser?

Note that the "admin" aspect also implies (to me) using it to control things in your home that IoT is more known for, so you could build an entire control panel for all of the "smart" devices in your home.

What else?

2 hours ago, David Heffernan said:

Because the computer has ARM processors would seem like the obvious reason

Brain fart. Sorry. 😕

On 11/26/2021 at 10:51 AM, Lars Fosdal said:

I added the preview version of Windows 11 for ARM to a Parallels VM

why the ARM version? I mean ... why not the Intel version?

I'm curious if there's much of a performance difference.

On 8/26/2021 at 3:50 PM, Vincent Parrett said:

This sort of task looks like something that OmniThreadLibrary would handle - but does require some study to get right (worthwhile imho). I created a wrapper over it's async/await feature that might be useful

 

https://github.com/VSoftTechnologies/VSoft.Awaitable (depends on https://github.com/VSoftTechnologies/VSoft.CancellationToken and omnithread) 

 

I notice that OmniThreadLibrary 3.07.9 (10/26/2021) has added this:

[HHasenack] Added Cancel and IsCancelled to IOmniParallelTask.

20 hours ago, Dalija Prasnikar said:

I agree with that.

 

Now, without going into whether Embarcadero is currently giving stable updates or not at the end of the line... In reality stability is possible only on Windows and Linux platforms

I was mainly referring to the Delphi IDE, which only runs under Windows. The other stuff from Embt doesn't interest me. They can't deliver a stable IDE in Windows; I certainly don't trust that their cross-platform tools are any better. Not hitching my wagon to them. No thanks!

Personally, I'm far more interested in using something like TMS WebCore for cross-platform development than native tools at this point, mainly because I've been watching how slowly Delphi as been getting updated and the inevitable bugs that show up after any major changes. TMS is way more responsive, and javascript seems to be far more stable running in all web browsers than trying to keep up with every update of mobile operating environments.

Yes, it might be a bit more limited, but I'd rather invest in a more stable and consistent UX/UI than constantly dealing with what Delphi's native platforms offer. 

There was a point in my life where I *LOVED* working with beta copies of software and chasing down weird issues, but not any longer. I want to just get in, get something done, and move on. I guess I have come to value getting stuff out of my head as fast as possible without having to take a bunch of detours to deal with potholes in the road. My memory is getting flakey, I have trouble remembering names of things, and each of those detours takes me longer to regain focus when I get back to where I was. 

We pay so-called "maintenance" fees to supposedly get bugs fixed. But when the maintenance runs out and then they say you need to renew it to get bugs fixed in the version you already paid for, it's unethical.

It makes the so-called "maintanance plan" nothing more than an annual license fee.

10.4.2 is reasonsbly nice but we should get a 10.4.3 that fixes the bugs introduced in 10.4.2, not forced to renew and then have to get D11 instead.

If I don't feel like upgrading for a couple of releases, that's ok, it costs the same either way. 

Since inline vars were introduced in 10.x, the refactoring stopped being useful. In 10.4.2, still not useful. But other new features were added. 

And in 10.4.2, when I use debug inspector and adjust width or the column splitter in the popup form, Delphi hangs. All you can do is kill it in Task Manager and restart it. This happens at least 50% of the time when I inspect variables while debugging. This should have been fixed a week after 10.4.2 shipped. Nope. I guess the problems with the web server stuff that only a fraction of customers use are more important than the debugger that freezes the IDE that everybody uses. PRIORITIES....

I also have a regular problem when looking at stringlists using the stringlist viewer. It throws repeated exceptions (via MadExcept) about some issue with a Boolean, and reloads the viewer many, many times. You have to close the exception box each time, and sometimes it just recurses so many times it's easier to just kill delphi and restart it. But other stuff was fixed with patches.

This crap was released under a maintenance plan. It should be fixed in a 10.4.x update, not requiring people to move to a newer version for resolution subject to renewal of the maintenance plan.

I honestly don't want to move to D11 at this time. Just more new bugs to deal with. I WANT STABILITY!

I'm really tired of every new release fixing some old bugs that should have been fixed before, then adding new stuff and more bugs.

We NEVER get to a point of STABILITY with ANY release!!!

What we can count on is that there will be a major new release every fall that will stop the previous version dead in its tracks and force you to upgrade whether you want to or not just to get older bugs fixed.

If you have an end-of-the-line update before a new release (eg, 10.4.2), another one should be released to everybody that fixes outstanding bugs that makes it stable without requiring you upgrade to the next version.

Customers paying for "maintenance" deserve a STABLE UPDATE at the end of a line before upgrading to a whole new release.

3 minutes ago, Jud said:

I was just using that as an example.  But I have a routine that tells me the number of logical cores.

That's why I said "(or 'n')"...

So, knowing that 'n' <= #cores, you can limit how many active tasks or threads there are to 'n', right? I would think the easiest way to do that is to set the size of the thread pool to 'n'.

(Sorry if that's too obvious.)

1 minute ago, David Heffernan said:

Machines have a fixed and well defined number of processors that can readily be queried. So it's trivial to know what N is. 

I was trying to get him to figure that out himself....

I haven't looked at the code, but is there anything special about the DHTML components that's required?

TMS has a new lib, TMS FNC WX PACK, that includes TTMSFNCWXHTMLMemo (among other things).

If I had to guess, you might be using the Observables to act as setters / getters for the HTML tags.

The TMS FNC components are universal components and work in all platforms that Delphi supports.

Specifically in this case, they work in WebCore (and WebCore VSC), which translates Delphi into javascript. You can get access to the js in several ways at the Delphi level.

I think an interface library that works in WebCore and uses TTMSFNCWXHTMLMemo would be fairly easy to write.

As for a regular VCL Delphi app ... not sure.

15 minutes ago, Jud said:

Is there an easy way to keep only 8 running in parallel at the time?

How do you know there are exactly 8 (or 'n') CPUs?

3 hours ago, Dany Marmur said:

the bank requested a fax so any actual text will be destroyed in that step anyway,

the paperwork can be submitted via FAX or printed and sent via snail mail. 

FAX is easier. 

My sister solved the problem with NitroPDF and combined all of the documents into a single large document, then added a header in the top margin with the required info.

15 hours ago, Bill Meyer said:

So the numbers are not specific to the page(s)?

No. It's a bunch of paperwork the bank wants that's already in PDF files, including a few years of tax returns.

They want an ID printed on every page of every PDF, then FAXed to them

All the same info on every page in the same place.

I wonder how long it will be before banks move their data systems into the 21st Century?

what's the image list for?

that works, but it's not nearly as nice as the Raize one. It's just the same rectangle with a tiny little "thumb" pointing down and to the left.

And I have to put one on every form.