Hello Jafar, my opinion that binary releases of Unicon shall be paired for 32 and 64 architecture with full package of features included. It means graphics, threads and so on. If someone wants to build his own special edition it's always possible from the sources. Best regards,Sergey Logichev 12.02.2016, 09:31, "Jafar Al-Gharaibeh" :Hello Unicon Users, While I am in the process of working on a new Windows Unicon binary release, I want to know what matters to you. I'm trying to reduce the amount of unnecessary work if we can avoid it. For the last few years, I have been producing four different builds, 32/64/concurrent/non-concurrent. 32 vs 64 are obvious probably people care about one or the other. The main reason I still provide non-cocurrent builds is that I believe there are users out there who still care about the native and super fast co-_expression_ switch compared to the pthread implementation that comes with the concurrent build. We hope one day we add support for native context switch to the concurrent version and avoid this situation, but that is a different story. My question is: are there users who care about this (having non-concurrent builds) and actively using it on Windows? The second issue is that withing a single Unicon build, we provide different versions of executable of iconx (iconx.exe, wiconx.exe, nticonx.exe), icont (icont.exe, wicont.exe) and unicon (unicon.exe, wunicon.exe). We have tried to get rid of some of these in the past, and we are till trying to do something about it. In a perfect scenario we only need three, iconx.exe, icont.exe, and unicon.exe, but because of how Windows deals with console vs non-console applications we end up with two versions of every executable. We have some solutions for this, but non of them is perfect (yet!). nticonx.exe is built with no graphics to avoid having to do event polling which gives it a slight edge in performance. In my testings at least, the gains are negligible. Are there users who actually use it? do you care if we drop it from our "main" releases? My Goal is to simplify the "official" release process and reduce the number of files and their sizes that we have to put in. We can still provide "special builds" between the official releases to accommodate different use cases to drop in feature x or add feature y for example. Your input is appreciated. Best Regards,Jafar ,--Site24x7 APM Insight: Get Deep Visibility into Application PerformanceAPM + Mobile APM + RUM: Monitor 3 App instances at just $35/MonthMonitor end-to-end web transactions and take corrective actions nowTroubleshoot faster and improve end-user experience. Signup Now!http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140,___Unicon-group mailing listUnicon-group@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/unicon-group--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
