📌MacType needs your help

[sammilucia]

The MacType rendering engine is a long-term, mature project that has come a long way since it first began in 2012.

There is still a lot of work to do, however, especially in making MacType more accessible to the average user, and improving the apps surrounding MacType (for example, rewriting MacType Tuner and MacType Wizard to make them more modern and maintainable).

If you're an developer, translator, or tester, and you are interested – or know someone who might be interested – simply reply here, or message us directly at @snowie2000 or @sammilucia and let us know. We'd love to hear from you 😊.

[wmjordan]

for example, rewriting MacType Tuner and MacType Wizard to make them more modern and maintainable

The Wizard appears to be decently good to me. I don't think it needs any rewriting.

For the Tuner, is it possible to monitor MacType.ini and the AlternativeFile (user ini) and automatically reload after those files are modified, reflecting the changes immediately?

After that, it enables MacType enthusiasts to write their own "tuner" application, which provides better interface to edit the .ini files. Since the changes are automatically reloaded, the "tuner" application has no need to offer a preview window, which significantly reduces the technical requirements for the programmers, yet still serves good user experience.

[snowie2000]

Monitoring a file and reload on change is not something hard to implement. However, it would be hard to sync all the switches and trackers on reload.

I'm thinking of adding another mode where users can type in a built-in editor freely and the preview windows will reflect what the profile would look like simultaneously.

[wmjordan]

another mode where users can type in a built-in editor freely and the preview windows will reflect what the profile would look like simultaneously

This is a typical way of implementation. It is OK if the full preview feature is hard to implement.

On partial preview versus full preview, I have a VS extension which allows users to modify syntax highlight settings offers preview window. The scenario is somewhat similar to the one in MacType Tuner. However, the most intuitive way is to present the effects on the whole editor, where various syntax highlighters are working and the ultimate effects are demonstrated. Thus the users of my VS extension can not only see their changes immediately on the preview window, but also on the editor window, where they can then observe the overall effects.

The full preview is extremely useful and helpful since the user can switch to other windows and immediately see how his rendition settings will come.

I am sorry that I don't know about the implementation of MacType, and it is so difficult to "sync all the switches and trackers on reload".

[snowie2000]

I was thinking long long long ago about a so-called debugging mode where mactype disables all the cache and hot reload the profile on-the-fly so that it can demonstrate what the final result looks like in real-time.

The problem is that:

1. Without cache, mactype is very slow.
2. Some settings require mactype to rebuild its alpha blending table which is also slow.
3. Applications with sandbox such as Chrome don't allow mactype to read files from disk.
4. It's easy to crash the system if you made a fatal mistake (especially like replacing a system font with an incompatible one, which happens from time to time)

So I eventually give up the idea.

[wmjordan]

You don't have to abandon the cache.

The slowness makes sense. Full preview does not essentially mean to be real time preview.
Issue 1 and issue 2 are not big problem actually.
Do what it has to do, including cache. Tell the user to "be patient", and it is possible to optionally or temporarily suppress the preview if necessary in the Tuner. For instance, the full preview only occurs after pressing a button named "refresh", or a check box titled "full preview" being checked...

Problem 3, 4 are some problems. But they are irrelevant to the full preview.
If reading from disk is disallowed, it is disallowed by any means. With or without preview, it is the same. Thus it is another problem.
If it is to crash, it has to crash. A red-alert should be presented to the user what he is going to do is dangerous.

[snowie2000]

If what you want is to reload the profile without unloading and loading the mactype, the "Restart" item in the context menu of the mactray is what all you need.
It calls an internal method to ask mactype to clear all its cache, reload settings from file and reinitialize everything necessary.

Replacing font is always dangerous. The problem is we don't know how dangerous it is until we apply it...

[sammilucia]

The Wizard looks and works fine, the only problem with it is it's difficult to maintain (Delphi).

These are good ideas, and good ideas are certainly a big way of helping! What I'm looking for also is people who can / will help with programming, UX, translating, testing, etc.

[snowie2000]

Anyone who would like to write a new wizard is totally welcome and possible. The interface current wizard used to generate thumbnails is open source. All the loading modes implementations are not secret either.

The reason I didn't publish the source of the wizard is that it relays on my private library and some modified commercial components and, it is a very early product of mine. It is so badly written that I'm not willing to do any large scale work on it.

The popular framework electron allows you to make beautiful and feature-rich applications which is great. However, it is way too big that it is sort of against the principle of MacType.

[ChicoThorn]

Hi! Well it looks like Microsoft is up to its old tricks... They've made some changes in Notepad.exe; exactly what I'm not sure... but in the newest version released with Insider's Build 18963 the text in the edit window as well as the menu items themselves are not being rendered with MacType. I did some experimenting and found that the new Notepad's text and menus will not render at all if using Registry mode. However when running in Services mode the text will render, the menus as well, but the cursor must first be hovered across the menu items or the whole window minimized then restored. In MacTray mode the rendering seemed to work sometimes, but not others. This was true in both Stand Alone and Compatibility options.

I saved a prior copy of Notepad from Build 18941 that still functions properly with all text rendered by MacType. See below for samples of both, as you can see the difference is pretty obvious. I also included the only blurb Microsoft provided in the Insider's blog about the new Notepad, although there's no mention of any change in how text is handled...

Maybe you guys can make sense of it... 😁

2019.08.20· Notepad Build 18963 vs. 18941 Comparison.zip

[snowie2000]

I think they have changed it to a metro app or a win32 transcoded UWP app which is, according to issue #494, not fully supported.

[ChicoThorn]

@snowie2000, Interesting... crazy how they have so many different ways to do the same thing (open apps, render type, etc.). I guess I'll stick with my workaround of using an earlier "unbroken" version of Notepad. Any hope that this odd type of app will be supported in future MacType releases? It'd be great if it were, especially if Windows starts to use this scheme for more apps in the future... 😉

[sammilucia]

@snowie2000 @ChicoThorn I think Microsoft's CEO Satya Nadella will move towards Metro for everything, and eventually deprecate the old systems in Windows (and other products). It makes sense from a business point of view

[snowie2000]

That means we need to figure out how the metro processes are spawned internally.

[ChicoThorn]

@sammilucia and @snowie2000. — I'm baffled as to why the new Notepad can be rendered by MacType in Service mode, but not in Registry mode. In my mind that would indicate that the necessary bits to make it work are present, but for some reason aren't being invoked in Registry mode... ? Is this a fair assumption? ...and if it can work in Service mode then it also seems there must be a way to get it to work in Registry mode as well.

Why am I so stuck on Registry mode? It seems to be the best and most complete way to enjoy MacType's rendering throughout the entire UI, without any unpleasant non-rendering surprises (that is until this new Notepad showed up on the scene). In Registry mode I don't have to fuss with hovering over a type element to invoke MacType's rendering (as is the case with several apps and programs when in Service mode; i.e., Task Manager, and the new Notepad). Registry mode's more seamless experience allows me to forget about font rendering issues and to focus on my work.

Any chance that maybe some tinkering would get Registry mode to work with the new Notepad? 😃

[sammilucia]

@ChicoThorn it could be that the new Notepad has code injection protection. Registry mode uses AppInit_DLLs which is not a recommended method by Microsoft.

MS are trying to make their platform more secure so it would make sense if they stop supporting AppInit_DLLs as an educated guess.

Registry mode also won't work if you have Secure Boot enabled (and we recommend you do) - for the same reasons.

Technically Service and Tray modes are the OS friendly ways to implement the kind of integration MacType does. (But yes as you say - not quite as complete.)

@snowie2000 and I threw around the idea of implementing an API for MacType, so other software could choose to support MacType

[ChicoThorn]

@sammilucia Ahhh... interesting about the AppInit_DLLs ... that explains a LOT! Basically I really like the Service mode too (except for the sometimes hovery-over-the-text-to-get-it-to-render thing). I've been running it about half and half the past week trying to settle on one or the other. But I'm going to do some screenshot comparisons to see if there's a real difference or just my imagination (...and I've been known to have an overactive imagination, so testing is essential, lol! 😁)

[ChicoThorn]

@sammilucia, @snowie2000 — Hi! 😀 So after many screenshots I came to the following conclusions: Registry mode renders everything in the UI really well EXCEPT the new Notepad. Service mode renders everything in the UI really well EXCEPT some alert windows (UAC and registry warnings), and that annoying hover-first-see-rendering-after thing that happens in new Notepad and in Task Manager. So I use Notepad a lot more than I need to see some alert screens brilliantly rendered so I've opted to make Serice my new go-to mode.

On my wish list: Fix it so when in Service mode the user doesn't experience the hover-first-see-rendering-after issue by next release ?? 😊

Service Mode vs. Registry Mode.zip

[sammilucia]

This is really great @ChicoThorn !

[Fidelich]

Hi, @snowie2000, want to present my russian translation of macType. Pls, add it to installer
Russian.zip

[snowie2000]

@Fidelich Thank you! We'll add it to the public release.

[snowie2000]

@ChicoThorn The reason that Registry mode stopped working is simply that it doesn't work for all UWP apps from the beginning.

You may wonder that it works for almost all the UWP apps like paint, calculator. That's because normal UWP apps are created from a process called runtimebroker.exe which is a normal win32 executable and can be hooked with registry mode, the processes created by it get hooked automatically by parent-children hooking mechanism.

However, as I mentioned before, notepad is a win32 converted UWP. Those apps have a very special launch mode and I'm still very confused about how they are created. MacType's parent-children hooking mechanism doesn't work for it and nor does the registry mode.
The reason it "seems" to work in service and tray mode is that the tray application/service works as a process monitor, it detects newly created process and applies mactype to them. The affected application should refresh its interface automatically by design, but for some reason, this auto-refresh method doesn't work in service mode, you have to hover your mouse to the interface to trigger a repaint.

To see the speciality of win32 converted UWP apps, here is an experiment you may like to try:

• start another instance of explorer.exe, there are many ways to do it, the simplest way is to run explorer , from run task dialog. You can start any amount of explorer instance as you like.
• Launch win32 converted apps from the created explorer windows
• Check process tree via process explorer/process hacker
• You'll see that no matter which window you clicked the shortcut, they are all child processes of the very first explorer.exe

---

• Launch any application that can invoke an open file dialog
• Kill all the explorer instances
• Open an open file dialog
• type *.* as a file filter so that you can see all the files
• Find a win32 converted UWP app shortcut and right-click it, select "open" to run it
• You should see a message box telling you an error like "class not registered" or something, and the UWP application can't be launched.
• Launch explorer from task manager and redo the step above.
• You should be able to run those apps again.

Have fun.

[sammilucia]

@Fidelich you are amazing! Thank you so much 😊 😊 I'm adding it right now. As @snowie2000 says, this will be in the next release 😊

[sammilucia]

@snowie2000 I think Win32 converted apps would be virtualised wouldn't they?

Some initial evidence this may be the case https://social.msdn.microsoft.com/Forums/sqlserver/en-US/4f2bf36a-835a-443e-b4fb-97e97a98d141/uwp-desktop-bridge-virtualization-issues?forum=wpdevelop

[sammilucia]

Some further research suggests there are several limitations of converted UWP apps, like they cannot be forced to run as Administrator. I haven't time to look into it in detail right now, but hopefully that helps?

[sammilucia]

@snowie2000 list of APIs supported only in packaged UWP apps https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

[ChicoThorn]

Thanks @snowie2000 ! — I'll give that experiment a try... should be interesting! 😊

[ChicoThorn]

Hi @snowie2000 and @sammilucia ! 😊

In my never-ending quest to find the perfect settings that work in nearly any point size and in either Dark, Light or Mixed Mode I do believe I may be getting very close! Check out my latest screenshots and .ini file. ChicoThorn.ini is now at version 1.5! WooHoo! 😁

First samples of my new settings at 113% scaling:

And here's the same .ini settings applied at 100% scaling:

The rendering settings from v.15 of the ChicoThorn.ini file

The new ChicoThorn - 113% - v.15.ini

ChicoThorn - 113% - v1.5.zip

And finally a .zip file containing all this new stuff...

{ ChicoThorn MacType Settings· 2019.10.11.zip

Let me know what you think! — I notice that the rendering of the Taskbar Jumplist at 100% in Light Mode is a bit thin, but still clear and readable. The grayed subheads on the Settings Page are also a bit light, but again I think they're workable. 😀

Oh! And as for the changes they made in Notepad so it no longer renders... I gave up trying on that one! 😉 Instead I found myself a nice 3rd party Notepad replacement app, which you've probably heard of: TED Notepad. Apparently it's been around for years, and is still being updated from time to time!

Gotta love and admire these independent programmers and coders who devote so much of their own time on these great Windows enhancements – I'm looking at you guys! You're the best! 😊

Thanks again for MacType and for your dedication to developing it further!

—Thorn

[ChicoThorn]

Hi again! So I was bothered by the fuzziness on the 100% rendering I sent above, especially in Light Mode, so I tweaked the settings a bit more and it's clearer now. That brings ChicoThorn to v.1.5.2 ! Since the fine-tuning changes I made will probably only be able to be seen in the original .png screenshot files, I'll just post the .zip with them in it and forego posting the screenshots here in the thread. 😀😁

The .zip file also contains the updated .ini file.

– Thorn

Screenshots .zip file:

ChicoThorn· 113%· v1.5.2· MacType Settings· 2019.10.11.zip

[namazso]

I'd say the current release is probably good enough for XP users. Also remember that the v142 builds still support Vista, which is 13 years old at this point, most machines should be able to handle that. Since VS 2017 has both C++17 and XP support, retargetting and hacking together their toolchain would still be an option to compile for XP (which they will need to anyways, since EasyHook bins are also built with v142 now).

On the other hand, updating to v142 would allow us to focus on bringing mactype to new platforms, like the ARM64 builds of Windows.

[namazso]

btw I just fixed the encoding on my branch (so I can edit and play around with the code without destroying the comments) by converting files both from Shift-JIS and GB2312 to UTF-8 and manually reviewing every single line and merging the correct interpretation. It was kind of tedious, but now I can edit code without destroying both kind of comments. Will PR after the current one is accepted since else it'd have some conflicts.

[sammilucia]

@snowie2000 @namazso I agree, there are versions that work well on XP and Vista. we can keep those hosted for people who need them, but by your own statement the newer versions don't work well on XP... we need to drop support for future versions so we can move forward. we're a very small team we need to choose our battles, and supporting every OS adds a lot of overhead, bug testing, etc. to do properly.

[ChicoThorn]

Hi everybody! I hope everyone is staying safe and staying well during the age of COVID−19 that we're all in. With all of us having more time on our hands, I thought I'd post my latest .ini file settings, my customized "Microsoft Sans Serif" font which I've used to replace both Tahoma & micross (Microsoft Sans Serif). My customized font is a duplicate of my glyph-customized SegoeUI font with widths and heights of U&lc being tweaked to provide a more eye-pleasing display on surfaces in the UI that default to Tahoma or micross. The result is a more unified experience across the UI.

My latest tweaks to the .ini file have proven so pleasing across so many different parts of the UI, that I haven't made any changes to it since February 21, 2020 (which is a long time relative to prior attempts). I have a series of steps I go through after each install of the Windows Insiders Fast Ring updates, and so far MacType continues to provide fantastic results (current Windows Insider Build is 19603.1000 released 2020.04.08). These steps are:

(1) Install my customized fonts for SegoeUI and Microsoft Sans Serif in particular.

Thorn Custom Fonts.zip

(2) Run MacWiz to reset the Mode used to "Registry" (I still find this mode to be the best overall way to load and use MacType in my experience, and since it continues to work, I will continue to use it). I also reload/reselect my desired .ini profile (although this appears to be unnecessary since it seems to persist build to build).

ChicoThorn-v1.5.1.0.8.zip

(3) Load my customized font substitutions into the Registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes

I exported a registry file with my custom settings a while back, so now after each build I just run that registry file to update Font Substituions more quickly.

Thorn Custom Registry Font Subs.zip

(4) I double-check my scaling options in Windows Settings —
Settings > Display > Scaling and layout = 100% (this setting persists build to build)
Settings > Ease of Access > Make text bigger = 113% (this setting also persists build to build).
I've found that these scaling settings work really well for a number of reasons. First off the 100% scaling makes older .exe apps continue to function properly (case in point is Microsoft Keyboard Layout Creator, which I use to change my keyboard layout to accomodate my customized glyphs. If the scaling is set to anything other than 100% this app no longer displays properly and becomes unusable). The 113% "Make text bigger" setting enlarge most of the Directwrite renderings in the UI (at least I think it's Directwrite, that all gets so confusing to me), including the Taskbar Jumplists, Action Center flyout, the Start Menu, UWP apps, Chromium Edge Canary and others).

(5) I use WinAero Tweaker to change the default font size of Icons from 9pt to 10pt (which also changes the sizes of all filename text displays in File Explorer). 10pt scaling of the Icons and filenames nearly matches perfectly the 113% scaling produced by the Ease of Access setting, thus providing a very uniform overall look and feel within the UI. Here's a link to WinAero for the download (scroll down past the adds for the download link) — Note: When you install WinAero Tweaker Windows will pop up a security warning that it's 'dangerous.' It is not. I have been using Tweaker for over five years with no problems. Sergey Tkachenko is the sole programmer with a small operation. The software is safe and reliable. https://winaero.com/download.php?view.1796
Here is the install files for WinAero Tweaker:

winaerotweaker.zip

(6) I make sure my monitor is adjusted and calibrated properly. — This one is important. It makes a HUGE difference in overall font display quality if monitor gamma, brightness, and contrast are improperly set. This took a little trial and error; but using calibration software (and my own eye) to adjust the overall look I was able to come up with very pleasing results. I imagine these settings would differ from monitor to monitor and brand to brand. For me these monitor settings are (input through the onboard settings of the monitor itself): Brightness=85; Contrast=75; Gamma=Medium. I also adjust the Nvidia Control Panel settings to a vibrancy level of 60%. All of these display/monitor settings have a big impact on display ultimately.

Finally, here are a few screenshots of my current setup at this time:

Screenshot Samples.zip

Edge Canary, Taskbar Jumplist, Action Center sample:

Custom MS Sans Serif Font UI samples:

File Explorer, Taskbar Jumplist, Settings samples:

Light Mode samples:

---

Thanks for all your hard work on MacType @snowie2000 and @sammilucia ! MacType continues to be the most important add-on to my PC and makes my everyday work so much more pleasurable and tolerable. I'm looking forward to helping out in the future as you develop new versions! Stay well everyone! 😊

[snowie2000]

Thank you, everyone. I'm starting to do a cleanup job now whenever I have time.
I'll start by gradually translating every comment into English.

[snowie2000]

Ok guy, we have a situation.

After merging the pr from the great @namazso, I have to rebuild mactype with easyhook32/64 instead of easyhk32/64, which means my previous easyhook needs a rebuild too.

After I rebuilt all the files, I discovered that the Chrome (Cent Browser) stopped working. MacType only applies to the mainframe but not the content. I then tried to debug by swopping files and turned out the easyhk64.dll is the key. When I used the old easyhk64 (renamed to easyhook64), chrome worked.

Then I compared the two versions of easyhook by asm, and they are basically the same except some differences made by the compiler which are not important at all.
I also managed to debug chrome and as I expected, LoadLibraryExW easyhook64.dll returned an error with error code 31 (ERR_GEN_FAILURE) which is really rare for this API.

I also clear the dllmain proc of easyhook and it still failed to load.
Also, everything back to work when I disabled the sandbox of Chrome.

Did anyone ever encounter similar problems? Are my old easyhook files sort of whitelisted?
Any thoughts are appreciated.

[sammilucia]

When I used the old easyhk64 (renamed to easyhook64), chrome worked.

If there really are only compiler differences between the old easyhk and new easyhook then my immediate thoughts:

1. Can't we just use the old easyhk and not worry about it?
2. Why would Chrome/Chromium whitelist easyhk? A quick google of "chromium and easyhk" turned up no source code debates (I'd expect some discussions)... In which case the only logical answers are a) you missed something in the ASM differences, or b) Cent have indeed whitelisted easyhk in an effort to continue to support MacType/GDI ... (b) seems like the only logical answer to me.
3. On this topic (of Cent Browser supporting MacType) we should try to establish a formal relationship for the sake of both parties. @snowie2000 have you a contact there? If not I can start this process

[kcohar]

Total noob here but is it possible that they could have *blacklisted *easyhook instead of whitelisting easyhk? Could this be a Cent-only problem or does it affect other Chromium-based browsers, or Chromium itself? That said, Cent may very well have whitelisted easyhk to enable MacType to work... I would if I wanted to make my browser more visually appealing.

…

On Mon, Apr 13, 2020 at 7:47 PM Samantha Glocker ***@***.***> wrote: When I used the old easyhk64 (renamed to easyhook64), chrome worked. If there really are only compiler differences between the old easyhk and new easyhook then my immediate thoughts: 1. Can't we just use the old easyhk and not worry about it? 2. Why would Chrome/Chromium whitelist easyhk? A quick google of "chromium and easyhk" turned up no source code debates (I'd expect some discussions)... In which case the only logical answers are a) you missed something in the ASM differences, or b) Cent have indeed whitelisted easyhk in an effort to continue to support MacType/GDI ... (b) seems like the only logical answer to me. 3. On this topic (of Cent Browser supporting MacType) we should try to establish a formal relationship for the sake of both parties. @snowie2000 <https://github.com/snowie2000> have you a contact there? If not I can start this process — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALJKQEZYOC2D6F5LDR2CUHDRMNF3RANCNFSM4HZOP6IQ> .

[snowie2000]

@sammilucia @namazso Mystery solved!

I tried several "mind-blowing" ways to see what has gone wrong with my easyhook, the here is the truth: The easyhook is blacklisted. @kcohar is actually right😆

Yes, it's not my previous easyhook that got whitelisted, it's the original easyhook that got blocked by all chrome variations. More specifically the dll whose original name is "easyhook64.dll" will be blocked no matter what it is.

My previous easyhook was built with the name "easyhk64.dll". Although its filename was later changed to easyhook64.dll due to our recent code refactor, its original filename was baked into the executable and didn't get modified along. My new easyhook, on the other hand, is built directly with the name "easyhook64.dll" and thus can't pass the barrier.

Proof: Change target name to anything other than easyhook64 and build and rename, the dll worked normally. Change target name back to easyhook64 and rebuild, chrome failed to work with it. Yeah, this is the fundamental difference I have discovered so far.

Based on the conclusion above, I think we should stay with my old "easyhk" solution.

[namazso]

I think it is not blocked rather accidentally (them not knowing of it), and it could very well be blocked in the future.

I'd say figuring out how to build and have it run statically would be an overall better solution (unless you know of something that prevents us from doing this?)

[snowie2000]

I found this:
https://github.com/chromium/chromium/blob/625baf57077a3a4c8663a02ec8fd6200c97fb494/services/service_manager/sandbox/win/sandbox_win.cc#L84

and this commit: chromium/chromium@8cf80aa#diff-a1af1f033b583d4d0a1155fea5d0a087

[namazso]

I meant that your build is only accidentally not blocked, however following the links to this it seems like they explicitly aren't blocking MacType, so it's probably all fine.

(regardless, I'll look into the possiblity of static linked easyhook, it would be nicer to do)

[sammilucia]

@snowie2000 that's amazing! - that's very lazy blacklisting if just renaming can work around it.

Great sleuth work!

[snowie2000]

I don't think it's good to embed all libs statically.
Mactype was mactype.dll/mactype64.dll before, and it's now a two-stage loaded program. The old mactype/mactype64.dll is now just a bootstrap and it loads the core.dll when necessary.

The bootstrap part and the core part shares the same easyhook library.
The reason it's now two dlls instead of one is because of the safety and performance. The bootstrap part only hooks APIs that create new processes. No font engine initialization happens in this first stage.

It greatly improved the performance of MacType for compilers because compilers tend to frequently create and exit new processes and they don't have any GUI.

[snowie2000]

@snowie2000 that's amazing! - that's very lazy blacklisting if just renaming can work around it.

Great sleuth work!

As I stated in the previous post, renaming doesn't work. You have to rebuild it from source code. Of course, it has never been a problem for hackers.

[namazso]

The bootstrap part and the core part shares the same easyhook library.
The reason it's now two dlls instead of one is because of the safety and performance. The bootstrap part only hooks APIs that create new processes. No font engine initialization happens in this first stage.

Oh okay, that's reasonable. Although I'd rather have a lazy initialization, since loading a bigger dll costs almost exatly the same (and cheaper than two) as long as it "does nothing" ie. no initialization happens, but I can already see how troublesome that would be if we wanted to not load things like GDI32 into non-gui processes

[snowie2000]

I have stripped the bootstrap part to make it entirely depend on kernel32.dll only (which is loaded into any non-kernel mode processes). There is hardly any way to make the core part like this and lazy load dozens of system DLLs.

Plus, the MacType core does a lot of initializations upon dll attaching (although lots of initializations have already been delayed or moved during its development), it would be very difficult to extract all those functions and invoke them at the right time.

[snowie2000]

As of CentBrowser 4.2 (Chrome 81) the easyhook* are now completedly blocked no matter which filename you built it with.

[kcohar]

What about regular Chrome (Canary) or Chromium?

…

On Thu, Apr 23, 2020 at 7:29 AM snowie2000 ***@***.***> wrote: As of CentBrowser 4.2 (Chrome 81) the easyhook* are now completedly blocked no matter which filename you built it with. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALJKQEZBYEWHIVOLIZSASS3RN7G2XANCNFSM4HZOP6IQ> .

[snowie2000]

I haven’t tested it yet. Cent is my daily driver.

[wigster]

Hi @ChicoThorn

(2) Run MacWiz to reset the Mode used to "Registry" (I still find this mode to be the best overall way to load and use MacType in my experience, and since it continues to work, I will continue to use it). I also reload/reselect my desired .ini profile (although this appears to be unnecessary since it seems to persist build to build).

ChicoThorn-v1.5.1.0.8.zip

I've installed your updated fonts etc and indeed a bunch of things look much nicer, but alas your modified Segoe fonts do not seem to contain a large part of the Central European character set, so I now have random symbols appearing instead of the character such as čš in the text.

I would like to go back to the orignal Windows-supplied fonts. How can I do that?

[ChicoThorn]

I would like to go back to the orignal Windows-supplied fonts. How can I do that?

Hi @wigster, Sorry about that, I forgot that many users would want to use the the Central European character set (which is where I embedded my custom glyphs). I'll need to create a version of my modified Segoe font that doesn't contain my custom glyphs in order for that to work properly. But in the meantime, it's fairly simple to return to the Microsoft supplied fonts and still enjoy MacType's amazing rendering.

(1) Reinstall the attached Microsoft default versions of the default Microsoft fonts for SegoeUI and MS Sans Serif (micross). Unzip them, then install these fonts into your system (both for single user and for all users)

Default Segoe & micross fonts.zip

(2) Unzip the attached "Default Registry Font Subs.zip"

Default Registry Font Subs.zip

— Open Regedit (Registry Editor) to the following address:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes

— In the left navigation pane you will see the "FontSubstitutes" Key highlighted. Right-click it, and select "Delete"

— Now, load the "Default Registry Font Subs" that you unzipped by clicking on the .reg file. Follow the prompts to add this to your registry. After you load it, you will now find the Key "FontSubstitutes" is back, but the list is parred down to the original default values provided by Microsoft.

(3) Unzip the "ChicoThorn - v.1.5.1.2.3 (this is my latest and best ini settings to date) - MS Fonts" zip file and copy it to your MacType ini folder (located in Programs > MacType > ini)

ChicoThorn - v1.5.1.2.3 - MS Fonts.zip

(4) Run MacWiz. Select "Registry" mode. Click Next, then on the select profile window select the new ChicoThorn ini file you just copied.

— Restart your computer. You should now have Arial, Tahoma, and MS Sans Serif all displaying as they normally would in a default Microsoft setup. Of course, you can always modify your font substitution lists in both the registry and the MacType ini file. I've found it's best if these two lists match up.

Hope this helps! Give it a shot and let me know how it goes. 🙂

[ChicoThorn]

The reason it "seems" to work in service and tray mode is that the tray application/service works as a process monitor, it detects newly created process and applies mactype to them. The affected application should refresh its interface automatically by design, but for some reason, this auto-refresh method doesn't work in service mode, you have to hover your mouse to the interface to trigger a repaint.

As you know Microsoft has indeed moved many of the Sys32 apps to the Store now... so I've revisited my Mode setting in MacType and have switched over to MacTray Standalone Mode. It works great even on those new converted 'old' apps. I'm still annoyed with the need to hover sometimes first for the rendering to kick in, but on the other hand it's a lot better than not having it render at all as is the case in Registry Mode on those particular apps. Thanks again @snowie2000 and @sammilucia for the insight you provided on this in 2019... it just took me awhile to come to the party! 😊

[SoftwareType]

@snowie2000 I'm not sure if you're the one making the wikis, but due to Supermium's capability to load in GDI Legacy and DirectDraw for compatibility reasons, it is actually possible to load it and make the websites have MacType to work!

I have modified my browser, but it should work first-run.
I'm using the latest BETA version of MacType from August, 2023

[snowie2000]

@SoftwareType yes, I can add it into the wiki.
BTW, is there any other modified browsers that still support GDI legacy?

[SoftwareType]

@SoftwareType yes, I can add it into the wiki. BTW, is there any other modified browsers that still support GDI legacy?

Firefox font changing does work at default, but when it doesn't support it anymore, it might be possible that https://github.com/Eclipse-Community/r3dfox/tags might be the next one to support it, but I highly doubt that it would be the case, since they didn't do much stuff with Fonts for a while

[SoftwareType]

@SoftwareType yes, I can add it into the wiki. BTW, is there any other modified browsers that still support GDI legacy?

Possibly everything that runs under Windows XP and Vista compatibility, has GDI Legacy on it.
I suppose that there might be something that just makes some of the DirectDraw apps still have the default ClearType function.

I know that this might be a bit of a harsh task (and issues might "blow up"), but I thought if you could use methods of symbols to make it have some more advanced features or better customization (Symbols method outside the Services one)

[SoftwareType]

Also just a question; how do I know if DirectDraw works to render? It feels like it sometimes fail in some places

[snowie2000]

Also just a question; how do I know if DirectDraw works to render? It feels like it sometimes fail in some places

That's due to the complexity of the DirectX series APIs. There are tons of ways to do the same thing in DX and MS is adding new ways literally every new version... so inevitably, there will always be something missing...