It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
What is a native client?
Is Native client same as thick client?
Can anybody explaing it for me?
Native client for me traditionally means not interpreted by a virtual execution environment or sandbox but executed by the CPU and bound to the operating system (think Win32). I'd contrast native with HTML, JVM, CLR, etc.
Thick client for me traditionally means some business logic executing on the client, (think WPF, WinForms) as opposed to web/browser or other lightweight presentation container where most business logic is executing on the (web) server and minimal logic is executing on the client.
Traditionally, the two distinctions are unrelated, with "native clients" often being "thick". However, with the introduction of devices this distinction has become skewed, since it's not crystal clear anymore if a native app on a little device can still be considered thick. Many people avoid saying "thick" and refer to "rich" instead.
Nishakant, since you asked this in context of my tweet, let me explain what i meant by it. Native in that context meant a native Windows 8 application, which in turn means an application conforming to the new modern UI guidelines, runs on WinRT and is downloaded and installed from Windows 8 Store and runs locally on the Windows 8 machine. It isn't a web application, but locally installed. You could co-relate it to thick client applications in regular desktop world.
Additionally, this particular application is built by Twitter itself and hence another subtle meaning to the word native
While a native client may be about anything (for example a Native American paying you to write software for him), I'd say that in terms of software, a native client is some piece of software that is compiled to CPU bytecode, as opposed to a piece of software that's compiled to bytecode, which is compiled to CPU bytecode by an execution environment (Java, .NET, etc.) when run.
I'm pretty sure that at present, the term Native Client is only used to refer to Google Native Client (NaCl), which is a tool for running native code from within a browser, and yes in this case, Google definitely can explain it to you.
I can only guess since there is lack of context. I guess the Native Client you refered, is related to Google Chromium, is that right?
Chromium is an OS base on web browser, which means developer should NOT be able to go deeper than the browser. No directly manipulating the hardware, or optimizing your code in a CPU level, things like that.
However the requirement is there, so the Native Client is a technology, which provides a sandbox, to run the Native code(not really native, just you wrote with typical native language) inside the web browser.
You can see it's not same as Thick client.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm creating a MMO game. I will be using TCP client/server communication. At first my approach was to write both client and server in C++, but now I'm starting to think if it wouldn't be easier to write server in C#.
Client is going to be written in C++ because it needs to be cross-platform, but server will always be on Windows system. I consider choosing C# because it has an easier way of handling threads, built-in XML parser, etc.
My question is if it would be a good solution? Performance is still important to me, so if choosing C# over C++ would have a drastic influence on performance, I'd stick with C++.
Also if you think it's good idea, do you know if there are any tutorials that present communication between C# server and C++ client?
Thanks in advance for answers.
The performance difference between C++ and C# is not as large as you might think.
For the communications, if you're bothered about performance, use sockets and something like Google Protocol Buffers or Thrift. If you're less bothered about performance, use HTTP and JSON or XML.
Using different languages for client and server forces you to rewrite quite a bit of things in separate languages I would personally want to keep in sync:
Serialization and deserialization, although you could of course use some library for that. Google Protocol Buffers come to my mind, as they are explicitly designed to save bandwith and work "cross language".
Almost every entity of your game will have a more or less common set of properties. When going with different languages, you would have to keep these in sync manually and probably write them twice. This is especially annoying with more complex setters ;)
You will want to have some shared logic to "emulate" server answers on the client. Its important to predict on the client side what the server does to get a "snappy" behaviour. And what could emulate that behaviour better then using the same codebase for server and client?
I would't see a great problem with performance when using C# on the server though. That shouldn't be an aspect that strongly influences your decision.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am wanting to start a new (open source) project, and I wish for it to be cross-platform on Windows and Mac OS X (Linux would be good, too!)
I am open for developing seperate front-ends for each platform, but the core logic should be shared.
I would need the following:
Preferably a native GUI widgetset
FTP connection (platform-independant wrappers)
A TreeListView (again, preferably a platform-independant wrapper)
I have been researching this for quite awhile now, and I find these solutions quite attractive:
Mono, using WinForms for Windows, and MonoMac for OS X
Lazarus (FreePascal) with LCL
Mono pros:
Uses C#, a very nice language to work with
Has widgetsets for OS X and Windows
Mono cons:
Mono Framework is a dependency for my application
Lazarus with FPC pros:
Pascal is a great language too, and I know how to work with the Indy controls for FTP.
Has VirtualTreeview, which is the best treelistview control I have ever seen!
Cross-compilation is possible
Also has widgetsets for Windows and OS X
No framework dependencies!
Lazarus with FPC cons:
It appears the support is dying, but maybe thats just me.
VirtualTreeview appears to only have ports for Windows.
Executables can get quite large, but that can be fixed.
I also looked into Delphi XE2 with FireMonkey, but it does not use native controls, and it does not look native, due to the anti-aliasing. :(
Now, my biggest concern is, that I cant seem to find a TreeListView that works for Windows and OS X! I really need a treeview with columns.
The big points go to the technology that has a cross-platform TreeListView that works and is still supported.
Thank you for your time!
I would strongly suggest against Pascal.
It is a dying language, and as you noticed support will diminish with time.
The chance of asking a question and getting an answer is much better with more modern languages.
.NET/Mono is one good option.
.NET has TreeView in WPF, but it's not implemented in Mono, and as far as I know, it never will be.
Another option I'd suggest checking out is Java (Or even better - other JVM based languages such as Scala).
It's very cross-platform(Maybe the most cross-platform language), support is good and language is still evolving (Although it was stuck for a few years), and the syntax+code style is very similar to C#(excluding support for LINQ, etc.), which makes moving from one to another pretty straightforward.
JVM is a prerequisite, but it's not really big problem, as it's already installed on most machines.
Years ago, I used Qt and wxWindows/wxWidgets for single-codebase UI for Windows and various *NIX variants.
Frankly, I haven't worked with them in years, nor I'm aware of how well they support Mac OS X, but they might be worth a look if you are willing to use C++ (they are both C++ libraries).
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I am assigned a project in which there are two parts :
Database Programming
Game Programming
I am incharge of Database programming and my partner the later. But I am friendly with C-sharp Database programming as it is very efficient using Visual Studio. But he has a Game experience in C++.
Our target system is Windows 7,database will be Sql Server Database, and game can be in C or C++.
We will have a link in Windows forms that starts the Game.
How do we solve this problem without changing our partners?
From a technical point of view it is possible to write a project in multiple languages. From a practical standpoint it is not a good idea.
If this is a small project that will not be enhanced and will be write once and forget then it is fine, otherwise not.
You don't necessarily need to change partners, one of you just needs to step up and say they will jump the learning curve. As a programmer you need to be able to work in whatever language is required.
There are many factors that decide which language/library to use. Write them down with the pros and cons and decide which makes the most sense for your application. Agree that once this is settled then the topic will not come back up. Maybe find an neutral arbitrator that you can both elect to decide for you.
A partner is more than their ability to write code in a given language. The coding part is a small part of the project.
I suggest looking at Managed c++ and the /clr compilation switch for c++. Using managed c++ you can expose what you need to the .net world using .net objects where appropriate, but use native c/c++ code internally.
Managed c++ also have alot of ways to integrate efficiently with .net, such as object pinning (no relocation by the gc)
c++ compiled with /clr can be consumed from any .net language like a regular .net assembly. c++ code compiled this way can also consume any .net assembly much like the other .net languages do.
You haven't provided much details about this game but can't you Process.Start the Game from your WinForms application and passing it the necessary parameters that you fetched from the database?
Another option would be to wrap the database in a COM object developed in .NET that the game, if written in C++ can consume.
I am working on a project right now (and recently completed a similar one) that combined C#, and C++ libraries using C++/CLI. The data collection and signal processing were all written in C++ (your game piece) and the forms, xml and plotting was all done in C# (your db piece). C++/CLI handled the impedance mismatch between the two languages. I actually ended up writing little more than a mediator class in C++/CLI (I find it much more pleasant to write in C#). I think this would work for you too. The only issue is that C++/CLI is not C++. In fact I would suggest that the C# programmer learn C++/CLI rather than the C++ programmer. My reasoning is that syntactical differences between the languages are rather trivial and the C# programmer can probably learn those faster than the the C++ programmer coming to grips to what managed code and .NET is all about. That said, if you both took responsibility for the C++/CLI piece you would have all the skill sets needed to tackle it with the minimum amount of pain.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I want to write a warehouse program which has near 80 clients.My program has to make some reports and control entrance and exit of commodities in warehouse and store data in SQL Server Database.I need to know that which one is better: using windows application which give me a lot of feathers or creating website which reduce my ability in using objects?I have to mention that my clients will not increase.
Why don't you create a webservice which does all the actual work. In that way it's quite easy to build either a windows app, a web app or both.
It's really easy if you use WCF.
Why do you say that it reduces your ability to use objects ?
I would always go with web application and not CSA (Client Server Application.
Reasons (Source: http://www.eforcesoftware.com/brochures/Web%20Benefits%20over%20Client%20Server%20Technology.pdf)
Web applications are easier to deploy (install on the server only) Gives workers
secure, easy and instant access to enterprise applications, information,
processes and people, no matter where they are located, from anywhere, at
anytime, using any device, over any connection.
o CSAs must have software installed on both the client and the server. You
must have people update both sides for software updates and upgrades
Web applications give easier access (all you need is a secure internet connection
and a browser)
o CSAs need to have the client piece installed and are more difficult to
share outside a firewall
o CSAs run slowly when you are not on the same network
Web applications are centrally administered. Enables IT staffs to manage the
centralized management of applications, simplifying their deployment, monitoring
and measurement.
o CSAs are more complex to centrally administer
Web applications require less processing power on the client
o CSAs require more processing power on clients and are more expensive
Web applications are more flexible (can be tailored to your needs easier). They
can easily be integrated with other agency systems and databases to provide a
seamless Agency wide system.
o CSAs are delivered as binary applications and are harder to customize
Web applications don’t require much training (everyone knows how to use a web
browsers and surf the Internet)
o CSA require more detailed training and takes more time for users to get
comfortable and then adopt the new system.
Have you thought about Silverlight?
It's basically a browser-plugin, but the Silverlight apps are almost as good as "real" Windows apps (Silverlight is a stripped-down WPF, basically).
It's a bit the best of both worlds - rich and powerful UI, and basically installed/deployed on a web server.
How website does reduce your ability to using objects? I am sure the server side of programming is still C# though if you use ASP.NET. Plus ASP.NET gives you a lot more flexibility in handling more user connections via IIS.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I know this project.The question is that "Can we create a real OS with Managed Code or the os that will create with this project is a hello world os?"
Operating Systems need to have full control on hardware.Can we do it with this one?
If there are any another project please tell me
Cosmos Project
Yes it can be done - see Singularity which is (was) a Microsoft research project to create an entirely managed operating system in "Sing#" (an extended version of "Spec#" which is itself an extension of C#). Its worth stressing that this was just a research project into the concept, and was never intended as a "full" operating system of the likes of Windows or Max OSX.
The source code is available on CodePlex - you can download the code, build it and run it yourself in an emulator (I've done it myself, its well documented and relativley easy although I can't remember the exact steps myself).
Parts of the system were written in assembly / C, specifically the bootloader and the lowest level x86 interupt dispatch code however this is essentially all but unavoidable (it is by its very nature very platform dependant - something needs to write the x86 instructions to control and respond to basic hardware). The low level interrupts are also not particularly interesting in terms of how the operating system actually functions, so I personally don't consider this as cheating the "entirely managed" definition.
Looking on the Wikipedia page for Singularity there are also 5-6 similar projects, including Cosmos and a couple of similar attempts that use Java instead of C#.
The focus of Singularity OS was on security and dependency, however whats also impressive is that according to some basic benchmarks in An Overview of the Singularity Project1 (PDF) the performance of their archetecture was actually comparable to that of other "more conventional" operating systems:
... these numbers demonstrate that architecture that we
proposed not only does not incur a performance penalty, but is often as fast as or faster than more
conventional architecture. In other words, it is a practical basis on which to build a system.