Status
Not open for further replies.

show-Zi

Level 23
Verified
Hi anyone try or know how to get 2.99.13 version? Thks
It seems that the beta version is no longer available due to downloads that have a validity period. Probably, the official version ver.3 will be released soon, so you have to wait for it.
Detailed development information on TinyWall can be found on Wilder.
 

show-Zi

Level 23
Verified
I just released a new beta, with yet another a big feature: UWP (Windows Store) app support. Please see Wilders post for details.
No new features from now on until v3 final, pinky-promise.
Thank you! I'll try it later! Wfc is not bad, but I want to create a rule from the log, so I want to migrate if there are no problems.

For @blueblackwow65 , this is good news
 

ultim

Level 2
Ver.2.1.15 has also been released for the official board. Currently trying. Connections to the previously failed Microsoft Store are no problem in this version. (y)
The only change in 2.1.15 compared to 2.1.14 is that it will not offer you an upgrade to version 3.0 if you are running a 32-bit machine. That is because TW v3 is 64-bit only.
 

ultim

Level 2
That choice of colors has been that way since TnyWall was born more than 8 years ago. I guess changing that now would confuse a lot of users.
But to try to explain why it is to: These colors are meant for the user. Green is the recommended setting and the normal mode, this is why green, it is supposed to encourage the user. Red is dangerous and not recommended because it allows all apps to go out. Red is used to discourage the user in this case. Yellow is not dangerous, so not red, but still a warning that the firewall is blocking everything, so any kind of networking will not work. The color of warnings is typically yellow everywhere else too.

I know these are not typically the colors that other firewalls use, but I wanted you to know what is the general idea here. TinyWall's colors make more sense if you think about them as status indicators to the user, and not as firewall rule colors.
 
Last edited:

show-Zi

Level 23
Verified
That choice of colors has been that way since TnyWall was born more than 8 years ago. I guess changing that now would confuse a lot of users.
But to try to explain why it is to: These colors are meant for the user. Green is the recommended setting and the normal mode, this is why green, it is supposed to encourage the user. Red is dangerous and not recommended because it allows all apps to go out. Red is used to discourage the user in this case. Yellow is not dangerous, so not red, but still a warning that the firewall is blocking everything, so any kind of networking will not work. The color of warnings is typically yellow everywhere else too.

I know these are not typically the colors that other firewalls use, but I wanted you to know what is the general idea here. TinyWall's colors make more sense if you think about them as status indicators to the user, and not as firewall rule colors.
Thanks for answering small questions. If that is the case, I can understand.:)(y)
 

oldschool

Level 50
Verified
New version up with reported issues from the past 24 hours corrected.
- Fix GUI crash on Windows Server 2012 R2
- Fix performance regression in Connections window
- Add special rule for Windows Defender to keep it whitelisted after an update)

Download [fresh and hot].

I think the UWP APIs really might not be supported on WinServer 2012 R2. Installing a UWP app is possible but not easy without the Store, so instead of trying if I can actually run a UWP app there, I searched on the internet. Things point in the direction that it is not supported, though proofs are circumstantial at best. Add to this that I don't expect people to run Store apps on a server anyway, so I ended up disabling UWP support on WinServer 2012 R2. I *did* check Server 2016 too, and all the UWP stuff works nicely there in TinyWall.

The performance issue of the connections window was totally my fault, an oversight and a regression in the previous beta. Fixed now.

As for Windows Defender, I finally realized (duh!) that the "special exceptions" system in TinyWall is the perfect way to handle such things. It is technically perfectly suited for the task. In the end I didn't even have to write a single line of code for Defender, all was done as a simple addition to the XML database. It might take up to 30 minutes after a Defender update to get the new version automatically whitelisted though. I also decided not the add it as a "recommended" special exception that is default-on after installation, because Defender in its standard configuration can upload your files to submit samples, so I couldn't do it in good conscience. Which means you'll need to enable it manually in the settings. Of course after that there is no need to add a rule manually anymore.
 
Status
Not open for further replies.
Top