@mufa

Does the R7 240 warm boot? I have the seemingly fairly similar R7 250 in my X1000, and it definitely does not warm boot (using the HD v.3.7 driver).

I've played around some more with linking with and without -N, and what effect that has on the resulting executable.

elf.library allocates tracked memory when loading a program, so the TrackedAddr tab in Ranger conveniently shows all the loaded sections and the addresses they live at (the sizes of all the tracked memory allocations exactly match the section sizes that readelf reports).

Ranger doesn't report the memory attributes of those allocations, so I wrote a quick'n'dirty tool to call IMMU->GetMemoryAttrs() for any address I give it. With this I was able to confirm that the only difference between code linked with -N and code linked without it is that the .text section is writeable with -N, and is read-only with the standard ldscript. .rodata and .__newlib_version are read-only for both both ldscript versions, and all the other sections are writeable for both versions.

Curiously, the .text sections are not marked as executable, at least not as reported by IMMU->GetMemoryAttrs(). The address of the loaded .text sections is notably different than all the other sections, so perhaps some other mechanism is used to set aside a block of memory as executable. (Maybe the segment registers joerg mentioned? This is an X1000...)

Leaving the code writeable is more of a risk, especially for a program like PassPocket that is trying to prevent malicious code from potentially messing with it. So I guess it's time to change my linking habits.

I was remembering the alignment incorrectly; it is actually 4K. When you're looking at a little Hello World program that's a few hundred bytes, a 4K aligment gap seems enormous.

As a test, I rebuilt my PassPocket program -- which was linked with -N -- using the normal ldscript. I got lucky with the alignment gap there; the program grew by only about 800 bytes, or less than 1%. Worst case it might have grown by nearly 4K, though that's still less than 5%.

To help understand the difference, I looked at the executable for both versions with a hex viewer. Both versions have an alignment gap between the .text section and the .rodata section, so .text can live in its own executable memory page. The page certainly could be made read-only as well, though the -N version's ELF file specifies it as writeable (is there a tool of some sort that would display this information?).

The standard version also has an alignment gap between the .rodata section and the .data section (and all the other writeable sections that follow), while the -N version does not. I suppose that makes the .rodata section writeable in the -N version, since it would live in the same memory page as the other writeable sections.

I'm not sure how big an issue that is. I guess if a bug causes the program to try to write to the .rodata section it would trigger a DSI that would point out the problem and allow it to be fixed, while the -N version would not get this protection. And there would be some degree of protection against some other program running wild and scribbling over the .rodata (or over the .text section, if that's write protected), though that's not something that's very likely to happen.

I've been following this thread with interest, as I've always used -N when linking my programs. IIRC, the alignment with the standard ldscript is 64K, which ends up leaving a lot of unused empty space in the executable on disk, and I suppose in memory as well. For modest-sized programs the waste is significant, and using -N substantially reduces it.

That's the benefit to using -N. Is there a downside?

@broadblues

Quote:
I can't confirm seeing the issue since I installed my new graphics card a few months ago. But neither can I confirm that I haven't seen it. I just got used to seeing the glitch now and then and stopped paying much attention to it. I upgraded the RadeonHD driver just before installing the new card, so I can't confirm seeing the issue with the newer driver, either.

Quote:
Definitely.

Quote:
The same as now. I only upgraded the card recently, so I ran for a long time with that version of graphics.library and the old card.

@walkero

Thanks for the status update- it's good to know that progress is being made. It seems like every day Odyssey loses the ability to access another web site that used to work, so work towards an eventual replacement is very welcome.

Quote:
Something to look forward to in the next SDK!

Quote:
Hopefully these ports will also show up some place like OS4Depot, where they're accessible to native developers.

@broadblues

I've got graphics.library 54.248, as supplied with Update 2. As far as I know, that's the latest public release.

@nbache

Quote:
I make regular backups of the entire system partition (and all the others), so I can restore the preferences if I need to. But you're right, making a temporary copy of just that directory would make restoring the preferences easier after playing around with them.

Quote:
I'm using DejaVu Sans 15 as my screen font, which is the one that's used for Workbench window titles. I think that's the default font, though maybe not in exactly that size.

I've also got a stock FE (Update 2) partition I can boot from, with no changes at all except for the graphics driver. But the problem with trying to use that, or experimenting with changes to the preferences, is that the glitch is so random and infrequent that it's not practical to try changing things to see if it makes a difference- even if I didn't see the glitch for days or even weeks I couldn't be sure that it was because of the change I made, or if it just hadn't happened to show up. Just as I'm not sure now whether changing the graphics card and updating the driver made a difference.

@Deniil

My old card was an HD6570, and I definitely saw the problem when I was using that card. I was using the old v. 1.7 Radeon HD driver at the time. I'm using an R7 250 and the v. 3.7 driver now; I'll keep an eye out to see whether the problem ever occurs with my current setup.

@tonyw

Quote:
I started with the standard theme, but have made adjustments to the various settings to suit my taste. Looks like I'm using the "Subtle" bitmap set for the window borders; I think that was the default set, but I don't recall for certain now.

Having spent a lot of time getting the look I want, and getting Reaction and MUI synchronized so everything looks consistent, I'm not inclined to change any of the settings now.

Quote:
graphics is 54.248, and diskfont is 53.13. Should be standard FE Update 2 stuff. Though as I noted, I had the problem when running Update 1 as well.

Quote:
I've never seen it anywhere but in the window title. It would be a more serious problem if it showed up elsewhere.

@rjd324

I've been seeing that for years on my X1000 (I thought I was the only one...), ever since I upgraded from 4.1.6 to FE Update 1. I was hoping Update 2 would fix it, but no luck.

As with you, it seems random and completely unpredictable. I've only seen it on Workbench windows, but it's inconsistent as to when it happens, and which window is affected (usually just one window, but not always). It seems more likely after I've been using the system for some time, but that's inconsistent, too.

Sometimes it takes the form of a solid line under the entire title, as in your screenshot. Other times it's only part of the title that's underlined. And sometimes it's more like an irregular dashed line that's different each time I open the window. I've even seen it change while the window is open.

It seems harmless, and doesn't appear to affect anything beyond the window titles. I've never even considered reporting it, since it's so random and irreproducible. I recently upgraded to a new graphics card and driver, but I've gotten so used to ignoring the glitch that I can't even say for sure if I've seen it since the upgrade.

@Cageman
@smarkusg

My SiteList file contains the following:


Where, of course, you use your actual user name and password. There's a return at the end of each line.

This issue has come up before, see post #8 et seq in this thread. Creating a proper SiteList file seems to solve the problem.

Speaking of confusion: Does anyone else get a blank page after clicking the 'Reply' button below post #4 in this topic? (If you do, the browser's 'Back' button will get you back to the topic page.)

I notice that post #4 has a matched '<' and '>' in it, just like the post I was trying to compose over in the "current situation with printing" topic that caused blank pages when previewed. Something weird seems to be going on with the forum software when those two characters are present in a post.

@rjd324

Looks like you've found the reason, which was indeed a multi-assign to C:. Curiously, 'C:' isn't present in the Assign list you posted, which makes it hard to see the problem.

@rjd324

Perhaps C: is multi-assigned, with the path to Python being one of the assignments? Try "Assign" by itself to see what the assignments are.

@tonyw

Quote:
Thanks for the tip. It didn't work- the page still goes blank when I preview the post (when I display the source for the blank page, it's blank too). However, it led me to try something different that did work.

There are two 'Preview' buttons on the post entry page. I've never been clear on what the difference is, but I normally use the lower one, as it seems to give a preview that more closely resembles the final post. That's the one that causes the page to go blank when there's a '<' (or an ampersand lt;).

However, when I tried the upper 'Preview' button the '<' appeared as it should. I tried submitting the post, and the '<' showed up, just as it did when using the upper 'Preview' button. So the problem seems to be limited to the lower 'Preview' button.

Incidentally, there's no problem when using the lower 'Preview' button with this post, so the problem isn't due just to the '<', but to the entire line of PostScript code in that particular post.

@Deniil

Are you sure that's where the message is coming from? Both ListDynDep and readelf -d indicate that AK-8SVX.datatype has no dynamic section, and therefore does not require any shared objects.

Double-clicking a datatype's icon normally runs "C:AddDataTypes", which adds the associated datatype to the system. But I notice that the default tool for the AK-8SVX icon is "MultiViewer:MultiViewer", which isn't really what you want (though MultiViewer doesn't use any shared objects, either).

Perhaps your default tool somehow got set to some other program?

@Raziel

Quote:
I added the following at the top of the file, just after '%%BeginProlog':


'/Duplex true' enables duplexing. Setting it to false instead disables duplexing, useful if you want to print something single sided and your printer is set to duplex by default.

'/Tumble false' sets the printer to flip the printed pages along the long side, book-style. Setting it to true instead tells the printer to flip the pages along the short side, calendar-style. False seems to be the default setting, at least on my printer, as even files sent directly to LPR: come out flipped on the long side.

It would be nice if a future version of the PrinterPS preferences editor (Enhancer?) had the ability to adjust these settings, and even nicer if the PostScript printer driver knew about duplexing. As it currently stands, you need to manually edit the postscript_init.ps file to change the settings. Fortunately these settings work for me 99% of the time.

Edit: Altered PostScript clip to have proper '<<' in it.

@livebyfaith74

I use LPR: with my networked HP laser printer. I tried a number of different network printer drivers when I first got the printer, and LPR: seemed to work the best (and it's OS4 native, unlike some of the others).

For programs that can generate PostScript output natively (like AmiPDF) I just send the PostScript directly to LPR:. For programs that don't generate PostScript on their own I use the Amiga PostScript printer driver, which is set to send its output to LPR:. (The PostScript driver has a passthrough mode that can send PostScript directly to the printer, but it's easier to just send straight to LPR:.)

My printer has a duplexer that can print on both sides of the page. The Amiga printing system doesn't know about duplexing, so I added a line to the postscript_init.ps file that the PostScript printer driver uses to enable (or, if I edit it, to disable) duplexing. That only works when using the PostScript driver, so I also set the printer to duplex by default, which works when sending PostScript directly to LPR:.

@joerg

Quote:
Thanks for this valuable bit of information. Media Toolbox has no popup help, so there's no indication what the 'Last ID' control does. Given that information, I can guess what the 'Last LUN' control does. But what about 'Last TID'?

Quote:
Indeed he did- thanks!